refactor(reading): single data_hex word identity, hash the token (#237)

[HugoFara]

Implements #237. Collapses the reading view's dual word-identity — a TERM<hex> CSS class and a data_hex attribute carrying the same value — down to data_hex alone, and replaces the 2011 ¤/hex StringUtils::toClassName() encoder with a short SHA-256 hash.

Design doc: docs-src/developer/word-identity-data-hex.md (status updated to Implemented).

Why

• Subtly-broken encoding. toClassName() iterated per character (mb_substr) but tested per byte (ord), so the ¤-sentinel / 165-threshold unambiguity scheme it was built around was never actually realized. PHP 8.5 surfaced the smell by deprecating ord() on a multi-byte string.
• Dual identity. The same value lived in both a class and an attribute; lookups were split across .TERM<hex> selectors and data_hex reads.
• Fragile extraction. The JS TERM([a-f0-9]+) extractors mis-handled tokens containing g-z/G-Z/¤ and silently fell back to data_hex.

A substr(hash('sha256', $s), 0, 16) token is pure [0-9a-f]: selector-safe (no CSS.escape), correct-by-construction for the occurrence-lookup regexes, and recomputed identically on the PHP and JS sides.

Why it's safe

• No wire-format change — the API hex field keeps its exact role; both sides recompute the same hash from WoTextLC.
• No styling change — the TERM class carried zero CSS rules (verified).
• No persistence — tokens are computed per render, never stored, so the format change can't desync anything.

The only thing given up is human-readability of the token in devtools (accepted in the proposal).

What changed

Layer	Change
PHP token	StringUtils::toClassName() → 16-char sha256 prefix (toHex() kept)
PHP emit (5 spans)	Drop TERM from the class, add a data_hex attribute — TextReadingService ×3, ExpressionService ×2. Server-rendered spans previously carried the token only as the class, so this adds data_hex.
JS emit	Remove the TERM${word.hex} class push in text_renderer.ts
JS selectors (9)	.TERM${hex} → [data_hex="${hex}"] (word_dom_updates.ts ×5, word_result_init.ts ×2, text_renderer.ts ×2)
JS extractors (2)	Drop the class-regex fallback, read data_hex directly (text_reader.ts, text_keyboard.ts)
Tests	Assert hash shape instead of ¤ output; migrate frontend fixtures/selectors; remove the now-obsolete class-name-fallback extractor test

Drift from the original proposal, resolved: the doc named 4 JS extractors, but word_actions.ts/text_events.ts had already been refactored away — only 2 remain. The stale TextProcessingTest.php reference also doesn't exist; the toClassName assertions live only in IntegrationTest.php.

Intentionally untouched: the numeric id="TERM<woId>" Table-Test element id (table_review_row.php, word_result_init.ts:191) is a different mechanism, and toHex() (independent, tested utility).

Verification

• ./vendor/bin/psalm --threads=1 — 0 errors
• ./vendor/bin/phpcs --standard=PSR12 (changed files) — 0
• composer test:no-coverage — no new failures (2 pre-existing ApiV1Test version-constant failures are unrelated to this PR and present on main)
• npm run typecheck, npm run lint, npm test (4432 passed / 47 skipped), npm run build:all — all green

E2E note (worth a manual smoke before/after merge): open a text, change a word's status, confirm all occurrences restyle at once — including inside a multi-word expression and on the server-rendered reading page (TextReadingService path), plus keyboard word-nav.