fix: resident sankey link colours, per-instance clip ids, dead code and stale docs

[RetroHazard]

This PR is stacked on #96, the comment audit, because it edits the locale headers that PR rewrote. Merge #96 first. GitHub then retargets this PR to main once that branch is deleted; if the branch is kept, retarget it by hand.

Summary

These fixes cover problems found during the comment audit.

Bugs

• Resident flows sankey link colours: SankeyLink now gets the same getNodeColor callback as the nodes. Before, the ribbons fell back to the library's positional colours and didn't match their end nodes. This is the same fix v1.6.5 made for the Outcomes sankey.
• Clip-path IDs (time-series-chart-shell.tsx): ported upstream's per-instance useId() suffix (bklit #226) verbatim, so a re-vendor won't show a diff here. Two time-series charts on one page (compare mode) no longer share a grow clip path.

Unused code

• Removed the 35 @utility classes and the .floating-tooltip block from index.css, which nothing references. I checked this across the whole codebase, counting classes pulled in by another's @apply. This is design-system audit C8 and roadmap step 28.
• Removed the unread legacy flag from nationalities.ts and residenceStatuses.ts, and the unused onSelect prop from LanguageSwitcherProps.

Docs

• i18n README: corrected the plural-rule description, checked against Intl.PluralRules.
• zh-cn and zh-tw headers: they contradicted their own strings on colon width, label order and number spacing; they now match.
• ARCHITECTURE.md: the Japan topology is ~21k vertices after simplification (~60k in the source).
• Locales: each non-English locale repeated the same resident-dataset banner seven times; the extra six are gone.
• Design-system docs: audit C8 and roadmap step 28 now mark the CSS part done. The Civic Glass artifact is updated to match. The rest of C8 is still open.

Verification

• npm run lint and npm run typecheck are clean, and all 804 tests pass.
• npm run build succeeds. The compiled CSS keeps every utility in use and none of the removed ones.
• Checked in the browser with Playwright:
  • every resident-sankey gradient uses its end nodes' colours;
  • compare mode renders two distinct grow clip-path IDs.

"v1.6.6" in the design-system docs is the expected next release number. Adjust it in both the repo copy and the artifact if the release is numbered differently.

🤖 Generated with Claude Code

https://claude.ai/code/session_01EM2gyDaCzsEd8EHX6RxPyB

---

Generated by Claude Code

[RetroHazard]

Policy events check (routine)

This PR doesn't touch src/constants/policyEvents.ts, but as part of a periodic pass I checked whether POLICY_EVENTS / RESIDENT_EVENTS need new entries under the file's own inclusion rules.

One gap worth evaluating: policy.residenceCard2026 (POLICY_EVENTS, period 2026-06, category operations — "Residence card meets My Number": combined residence and My Number cards entered service) has no counterpart in RESIDENT_EVENTS. The only existing RESIDENT_EVENTS entry about the residence-card system is residents.markerResidenceCard at 2012-12, categorized reporting because that change moved the basis the population count runs on (alien registration → residence card). If the 2026 My Number integration similarly changes what or how residents are captured in the register — not just the card's form factor — it likely deserves a matching reporting-category entry in RESIDENT_EVENTS, pinned to the first half-year snapshot that could show it (2026-12, per the existing "first snapshot that could reflect it" convention). If it's purely a card-format change with no effect on the underlying count, no addition is needed — worth a quick confirmation either way.

Everything else currently in the file looks consistent with its documented rules:

• policy.act2026 (fee-cap legislation, 2026-06) has no resident counterpart, matching the precedent that fee-only changes (feeRevision2025) don't get one — fees don't move population figures.
• digitalNomad and sswExpansion (both 2024-03) fall in the same half-year as the existing markerTraining entry (2024-06) and are incremental/narrow-scope rather than new-category changes, consistent with RESIDENT_EVENTS staying deliberately "sparser" per its own header comment.

No blocking issues here — just flagging the residence-card entry for evaluation.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_019o7iXRKJVm3ebvBx3xD4qn

---

Generated by Claude Code