Design: converge call_sites[]/accessed_symbols[]/local_variables[] with the body{} projection (TS parity)

[rahlk]

Cross-analyzer divergence found comparing v2 wire formats: codeanalyzer-typescript consumes its internal call-site/local-variable facts to build body{} call nodes and then drops the lists from the wire (emit.ts v1-only field strip); codeanalyzer-python emits both — the body{} projection and the per-callable call_sites[] / accessed_symbols[] / local_variables[] lists — a redundant double representation of the same facts.

Why python still has them: the lists predate the v2 body projection and carry detail the body call nodes don't — structured arguments (ast_kind/inferred_type), receiver_expr/receiver_type, is_constructor_call — and the python-sdk actively reconstructs all three (PyNeo4jBackend rebuilds call_sites/local_variables rows for local ↔ Neo4j parity; reconstruct.accessed_symbols rebuilds from accessed_symbols_json).

Converging requires a keystone decision, not an analyzer-local edit:

1. where the per-callsite argument/receiver detail lives once the list is gone (enriched call body nodes?);
2. whether accessed_symbols/local_variables become body-linked facts, graph-only rows, or are dropped;
3. matching SDK model + both-backend changes and golden regeneration;
4. whether TS should instead add the detail python has (the lists may be the richer format worth keeping).

This is schema v2 evolution spanning codeanalyzer-python, codeanalyzer-typescript, and python-sdk → enters via designing-cldk-changes with a spec + epic; parked here until that rung picks it up.