Finishing: v2 migration guide, CHANGELOG, lockstep release train (rc.* → 2.0.0)

[rahlk]

PROBLEM

The v2 uptake changes what is under every accessor (seven documented semantic shifts), retargets three analyzer pins, and rides a multi-release train (2.0.0-rc.* -> 2.0.0 -> 2.1.0 -> 3.0.0 fast-follow). Without coordinated docs and release sequencing, users hit the shifts blind and pins race ahead of releases.

SCOPE BOUNDARY

Docs, release coordination, and verification only — no feature code. Announcement cleanup follows the repo's existing release-announcement convention.

GOALS

1. Migration guide: each of the seven shifts with a before/after example (graph node keys -> can:// ids; .code as slice; call-site payload thinning; rich edges retiring; externals re-materializing; JSON string content; AnalysisLevel L1-L4).
2. CHANGELOG entries per release-train stop; README + CLAUDE.md supported-languages table updated in the same change (repo rule).
3. Release execution: 2.0.0-rc.1 (TS+Py) as soon as F1-F6 TS/Py scope is green; final 2.0.0 only after the Java lane (codeanalyzer-java child + python-sdk#228) completes; lockstep checklist enforced (pin only once both sides are cut).
4. Release announcements posted and cleaned per the repo convention (this repo + org mirror).

CAVEATS AND KNOWN RISKS

• The rc window may be long (Java lane) — rc release notes must state clearly which languages are v2 and that Java is pending.
• Deprecation-policy text for the legacy getters lives with breaking(query): legacy getters become chain sugar + deprecation policy #219 (2.1.0), not here; this issue only records the train.

DEFINITION OF DONE

• Migration guide + CHANGELOG merged; supported-languages table current.
• 2.0.0 tagged with every epic child green; announcement posted and cleaned.
• Pins verified in lockstep at each train stop.

Part of #238