Support the figure_group node: outline, panel crossrefs, new lint codes

[dereuromark]

Closes #79.

What was already done

Re-measured against main at 9efaca0 before planning, because part of this
ticket had landed. #82 already added folding, the semantic-token case scoping
the opener's kind word and collecting the group caption, the hover description,
and figure in ::: completion - plus the engine pin that unblocked the
ticket. None of that is repeated here.

The diagnostics bullet also needed no implementation. The engine emits all
five §4c codes and the server passed them through verbatim already; nothing
pinned that, so a passthrough that stopped working would have been silent. Each
of the five now has a test, with a well-formed group as the control.

The schema ingest bullet has no work in this repo: there is no
resources/ast-schema.json here and nothing validates wire payloads. The only
hits are inside the tests/spec submodule, which is the spec repo's own copy.

The premise that moved, and what it changed

The ticket reads as though panel crossrefs are the gap. They are not the gap;
they are one case of it. The server resolved no caption crossref at all -
not a group's, not a panel's, and not the plain captioned figure's that predates
composite figures entirely. Measured on the pinned build before any change:

{#fig}
![p](p.png)
^ Figure #: Plain

See </#fig>.

definitionAt on that </#fig> returned null; </# completion offered
nothing for it; find-references answered nothing; and hovering it reported
Heading with the #-through-###### blurb, because no case existed for the
reference and the lexical fallback matched the # inside it. The engine
resolves it fine - carveToHtml writes <a href="#fig">Figure 1</a> - so this
was a server gap, not a dependency one.

That changed the shape of the work rather than its size: implementing "a panel
id resolves as the group's number plus a letter" on a server that resolves no
caption ids would have been building the second floor. This PR makes crossrefs
reach captioned hosts generally, with the group and panel rules from §4c as the
cases that motivated it. That measurement is recorded on the ticket alongside
the plan.

What this adds

src/captions.ts collects the captioned hosts a </#id> can name - figure,
table, figure_group, and a group's panels - each with its id, its host
position, and the text the reference resolves to. Completion, definition,
references and hover all read it.

The NUMBER is the engine's own resolved caption_number, not a re-derived
sequence: PART 9R R5 lives in the engine, and a second copy would drift the
first time a label sequence changed. Only the panel LETTER is derived here
(panel order among panels, a..z then aa), because no engine API exposes it - and
the tests pin it against the anchor text carveToHtml writes for the same id,
so a change to the letter scheme upstream fails here rather than diverging
quietly in an editor.

Panels are a group's DIRECT figure and table children, so stray content
between them takes no letter and does not shift the letters around it. An
unnumbered group registers anchors without crossref text for itself or its
panels, matching what the engine renders and what §4c states - and completion
leaves such an id out rather than offering a reference that renders as literal
text.

The outline gains the group: named by its caption, with its panel count as
the detail and its panels nested under it. It takes no heading level, so it
hangs under the section it appears in and never closes one. A panel with no
caption of its own falls back to the letter a crossref would use for it. A
panel yields no entry itself, but the walk still descends through it, so a
heading inside a quoted panel stays in the outline where it was.

Review findings

codex review --base origin/main ran after each step. Four findings, all
verified against the code and all real:

1. Completion offered ids that cannot resolve. An unnumbered host's id is a
   real anchor and a [text](#id) fragment link reaches it, but a crossref to
   it renders as literal text - so it was the one entry in a list of working
   references that quietly did not work. Filtered out; the "Unnumbered figure"
   detail string went with it rather than staying as a branch nothing reaches.
2. Find-references answered from a usage but not from the declaration, which is
   half of what the module documents for every other family. Added - and while
   adding it, the shape test I first put on the declaration line
   (/^\s*\{.*\}\s*$/) turned out to be a check that could only reject a right
   answer: a host has an id only because a block-attribute line gave it one, so
   the line above it IS that line, and the pattern only rejected spellings of it
   such as > {#fig} inside a block quote. Removed, with the weak control that
   passed either way replaced by two that do not.
3. The declaration lookup is matched by LINE, so running it inside the heading
   family put it ahead of link references: a host line carrying ![alt][img]
   answered the FIGURE's references for a cursor on img. It moved to the end
   of the chain, where a line-matched family belongs.
4. Reusing the heading usage scan reported every [text][] whose slug matched a
   caption id. That collapsed fallback is heading-only (PART 9R R1) - [foo][]
   beside a figure {#foo} renders as literal text - so the scan is now scoped
   to a heading declaration, with the same spelling against a heading as the
   control.

The fifth pass came back clean.