docs(rtl): make the extractor table say what NORM and TRIM do

[shigarov]

Documentation only — no behaviour change, no version bump.

The extractor table

	before	after
NORM	Collapse whitespace	Trim + collapse internal whitespace
TRIM	Trim	Strip leading/trailing whitespace only

TRIM's cell defined the extractor as itself. NORM's was incomplete: norm_whitespace is java_strip plus run collapsing, so NORM is strictly stronger than TRIM rather than orthogonal to it — the old table gave the opposite impression. Both rows now match what docs/model/atp.md already said for the same extractors, and the "only" in TRIM's row carries the contrast.

This table is also the source of the rtl-lsp hover dictionary — vscode-rtl/tools/gen_hover_data.py harvests it — so the VS Code extension was showing TRIM → Trim as its tooltip. Verified: regenerating against this branch changes exactly those two hover entries and nothing else. That regeneration belongs to the vscode-rtl side and is not part of this PR.

Deliberately not adding a cross-reference to the delimited specification here. TRIM applies to any atom — atomic cells, compound segments and delimited tokens alike — and singling out delimited use would invert the relationship: it is the "Semantics of S_delim" section that points at the extractor. It would also be misleading, since =NORM trims just as well, and would break the register of a table whose every other row is a bare effect phrase.

Broken anchor from 0.5.0

mkdocs build --strict reported:

Doc file 'rtl-reference.md' contains a link '#atomic--contspec', but there is no such anchor on this page.

The link was added in the 0.5.0 S_delim work, carried over from the jRegTab wording where GitHub's slugifier produces a double hyphen. The docs here are published with mkdocs, which renders ### Atomic — contSpec as id="atomic-contspec". Fixed; the build no longer reports it.

mkdocs build --strict   clean
pytest tests -q         1918 passed

🤖 Generated with Claude Code