test(docs): resolve every relative link, and fix the eight that went nowhere

[DemchaAV]

Why

Nothing in this build read a link. No test followed one, no CI step checked one, and
there was no link checker anywhere in the tree — I looked for one before writing this,
because the follow-up item was phrased as extending the link guard, and there was
nothing to extend.

That leaves two defects invisible by construction:

• Renaming a heading breaks every jump to it, from anywhere in the tree.
• Moving a file breaks every link into it.

Both look harmless in a diff, and neither is visible without clicking. I created one
myself in #502 — #the-value-label-halo — and nothing would have told me if I had got
the slug wrong.

What

DocumentationLinkGuardTest resolves 1051 relative links across 99 pages — docs/,
the root pages, every module README. File targets must exist; anchors must be produced by
a heading in the target page, computed with GitHub's rule.

External http(s) and mailto: targets are deliberately untouched: they fail for
reasons this repository does not control, and a guard that reddens because somebody
else's server is down is one people learn to ignore.

It found eight dead anchors, all in the examples catalogue:

Kind	Count	Fix
Missed by one hyphen — the em-dash in CV — single template is dropped and its two surrounding spaces collapse to --, not -	5	link corrected
Pointed at sections that no longer exist	3	name kept, link dropped — each row already carries working PDF and Source links

Getting the rule right took four measurements

Three were wrong, and each produced confident false positives. They are recorded in the
code so the next reader does not repeat them:

• GitHub does not trim the leading hyphen a stripped emoji leaves — ## 🚀 Start here
  anchors as -start-here. Trimming it condemned a working link.
• GitHub keeps the text inside backticks when anchoring — ## `MissingBackendException` when opening a session
  anchors as missingbackendexception-…. Stripping code spans from headings invented a
  different anchor and condemned another working link.
• A link written inside an inline code span is prose about syntax —
  `[text](#heading)`-style links — not a link. Two of those were flagged before I
  stripped inline code from the link scan (but not from headings, per the point above).

The first measurement said 24 broken. The real number is 8.

Tests

./mvnw -B -ntp clean verify → BUILD SUCCESS.

Checked from both sides rather than trusted because it went green:

Injected	Result
[gone](./no-such-page.md)	fails: docs/recipes/charts.md -> ./no-such-page.md = no such file
renamed ### The value-label halo	fails: #the-value-label-halo = no heading in docs/recipes/charts.md anchors there

The test also asserts a floor on how many links it examined. "No broken links" and "no
links read" are the same shade of green, and a regex that quietly stops matching would
leave the documentation exactly where it started. Verified that assertion can fail by
raising the floor: it reports only 1051 relative links were examined across 99 pages.

Not added to the fast guard job's -Dtest= list — that list is a curated subset and the
reactor gate runs this either way.