Summary

This issue describes three independent technique-label inconsistencies for CHA/points-to edges across the WASM inline, native post-pass, and native-orchestrator paths. This PR fixes the first (the one with no correctness risk); the other two need their own follow-up.

Fixed here: (a) WASM/JS inline CHA path missing the super-dispatch distinction

emitChaCallEdgesForCall (stages/build-edges.ts, the WASM/JS full-build inline CHA resolution path) tagged every dispatch edge 'cha' regardless of receiver kind. buildChaPostPass (same file, a different integration point) and the native orchestrator's this/super handling both already distinguish super-dispatch (not virtual dispatch) from typed-receiver interface dispatch. Added the identical call.receiver === 'super' ? 'super-dispatch' : 'cha' check, mirroring buildChaPostPass exactly.

Verified against tests/fixtures/cha-dispatch/ with --engine wasm: Lion.speak -> Animal.speak and Car.constructor -> Vehicle.constructor now correctly get technique='super-dispatch'; typed-receiver dispatch (dispatch -> ConcreteWorker.doWork/MockWorker.doWork) keeps 'cha'.

Not fixed here — needs its own follow-up

(b) Renaming native's 'cha-expanded' to 'cha'. I initially attempted this as a straight string rename (per the issue's own suggestion) but found it breaks a real invariant: expandChaEdges's exclusion filter (e.technique != 'cha-expanded') exists specifically to avoid re-expanding this pass's own prior output on a later incremental rebuild, while still treating 'cha'-tagged this/super-dispatch edges (from runPostNativeThisDispatch) as expansion-eligible input in the same pass — collapsing both labels to the identical string 'cha' would make the exclusion filter also exclude the this/super-dispatch edges it's supposed to expand (e.g. the PostMixin.m → B.m → sibling-override scenario the code comments describe). Fixing this needs a distinct internal marker (not necessarily the same as the externally-reported label) — a small but real design task, not a mechanical rename.

(c) Native full-build's own points-to/alias resolution has no technique label at all. Traced this to the FFI boundary: Rust's ComputedEdge struct (crates/codegraph-core/.../build_edges.rs) has no technique field whatsoever — native never writes technique at insert time for any edge, resolved via alias or otherwise; it all comes from the later JS-side blanket 'ts-native' backfill, which has no way to know an edge was points-to-resolved specifically. Giving these edges a distinct 'points-to' label requires either a new Rust→JS data channel (a list of points-to-specific edge pairs alongside the main edge list) or adding a technique field to ComputedEdge and threading it through the napi binding — a cross-language interface change, out of scope for a quick fix.

I've left #1996 open (not closing it) so (b) and (c) stay tracked; this PR title/commit uses Refs #1996 rather than Closes.

Verification

• npx tsc --noEmit: clean
• npm run lint: clean
• npm test: 260 files, 4207 passed, 30 skipped, 2 todo, 0 failed
• Extended tests/integration/phase-8.5-cha-dispatch.test.ts with technique assertions for both engines — pinning what's now consistent (super-dispatch) and explicitly documenting the still-open cha vs cha-expanded gap (b) as a known, separately-tracked difference rather than silently asserting something untrue