Guard ref() handling and centralize fragment label ranges

[MrCoder]

Context

• In invalid DSL like ref(), ANTLR error recovery synthesizes a NameContext so RefContext.prototype.Content() returns a context even when no name was provided. This can surface as an editable label/range at runtime for an invalid input.

What happens today

• FragmentRef uses ref().Content() and token start/stop to build labelText and labelPosition. For ref(), this.name()[0] can be a synthesized node, producing misleading UI/edit ranges.

Proposal

1. Add a safe helper for fragment refs: labelRangeOfRef(ctx) that returns an inclusive [start, end] or [-1, -1] when the first name is missing/synthesized.
2. Harden RefContext.prototype.Content to return undefined for synthesized names (e.g., start/stop tokenIndex < 0) or empty formatted text.
3. Update FragmentRef to use the helper + guard (render empty label and non-editable range when undefined).
4. Add focused tests covering: ref(a), ref(a,b,c), ref() + recovery, and mixed whitespace/quotes in names.

Why this aligns with our direction

• Keeps label/range logic centralized in helpers (like labelRangeOfMessage).
• Maintains renderer/parser decoupling and consistent editing behavior.
• Plays nicely with the IR adoption: no parser internals leak into components.

Out of scope

• Changing the grammar to accept empty refs. This is purely runtime tolerance and UX.

Acceptance criteria

• ref() produces no editable label (labelRange [-1,-1]) and no runtime warnings/errors.
• Existing valid ref(...) labels remain unchanged.
• Tests pass across the new cases.