feat(resolver): phase 8.3b — extend points-to analysis to native Rust path

[carlos-alm]

Context

Phase 8.3 implemented a field-based points-to analysis for the JS/TS fallback edge-building path (buildCallEdgesJS). The native Rust path (buildCallEdgesNative) does not benefit because the constraint solver lives entirely in JS/TS and is not forwarded to the Rust FFI.

Both engines must produce identical results (per CLAUDE.md). Currently the native engine produces fewer call edges than the WASM/JS path for code using function-reference aliases.

What needs to happen

1. Serialize fnRefBindings — add fn_ref_bindings to the NativeFileEntry FFI struct (already defined in build-edges.ts and passed to native.buildCallEdges). The FnRefBinding shape (lhs, rhs, rhs_receiver) is simple and maps cleanly to a Rust struct.

2. Implement the constraint solver in Rust — mirror buildPointsToMap / resolveViaPointsTo from src/domain/graph/resolver/points-to.ts in the native crate (crates/codegraph-core/src/). The algorithm is Andersen-style fixed-point propagation (≤ 50 iterations), already small enough to inline into the call-edge builder.

3. Apply pts fallback in native call-edge builder — when the Rust resolver finds no targets for a dynamic=true, receiver-less call, consult the pts map and retry.

4. Parity test — add a resolution parity test case that includes a const fn = handler; arr.map(fn) pattern and asserts both engines emit the same call edge to handler.

Related

• Closes the parity gap introduced by feat(resolver): field-based points-to analysis for higher-order calls (phase 8.3) #1289 (phase 8.3 JS-only implementation)
• Follows the same pattern as the Phase 8.2 native parity work