fix(wasm): preserve dyn=1 when deduplicating edges with same source/target/kind/conf

[carlos-alm]

Summary

• In the WASM engine's query path, a bare @Log decorator (emitted as dyn=1, dynamicKind=reflection by handleDecorator in runCollectorWalk) was being silently dropped when @Log() (a call-expression decorator, dyn=0) was already processed first and added to seenCallEdges
• Adds a dynZeroEdgeRows map (parallel to ptsEdgeRows) that tracks the allEdgeRows index of any dyn=0 direct-call edge; when a subsequent call for the same pair has dyn=1 AND an explicit dynamicKind, the existing row is upgraded in-place to dyn=1
• The dynamicKind guard prevents generic dynamic=true alias/callback calls (f.call, f.bind) from incorrectly upgrading dyn=0 edges

Test plan

• node scripts/parity-compare.mjs --langs dynamic-typescript → PARITY OK (was DIVERGED)
• node scripts/parity-compare.mjs → 41/42 fixtures pass (jelly-micro fails due to pre-existing bind.js issue filed as fix(parity): jelly-micro bind.js: WASM emits dyn=1 for f.call/bind aliases, native emits dyn=0 #1687, unrelated to this PR)
• npx vitest run tests/benchmarks/resolution/resolution-benchmark.test.ts → 206/206 tests pass
• TypeScript build passes with no errors

Closes #1683

[greptile-apps]

Greptile Summary

This PR fixes the WASM engine's edge-deduplication path so that a bare decorator (@Log, dyn=1, dynamicKind=reflection) is no longer silently dropped when a call-expression form (@Log(), dyn=0) for the same source/target pair was already recorded. It also adds parity improvements to the native Rust engine (RES-3/RES-4 resolution steps for JVM reflection and Kotlin member callable references) and aligns the Kotlin extractor's behaviour for invoke calls with the WASM path.

• build-edges.ts: Introduces dynZeroEdgeRows (a Map<string, number> from edge key to allEdgeRows index) that tracks newly emitted dyn=0 direct-call edges; when a later call for the same pair carries dyn=1 and an explicit dynamicKind, the existing row is upgraded in-place via row[4] = 1 and removed from the map.
• build_edges.rs: Adds RES-4 (pre-qualified Receiver.name lookup for Kotlin member references) before the same-file fallback, and RES-3 (resolvedType.keyExpr and CallerClass.keyExpr lookups for JVM getMethod/invokeMethod reflection), both scoped to non-JS/TS files.
• kotlin.rs: Suppresses the previously emitted <dynamic:unresolved> call for .invoke(…) callable-reference invocations, removing an unresolvable synthetic node that the WASM path never produces.

Confidence Score: 4/5

The change is well-scoped and verified against the full parity test suite; the core decorator-dedup fix is straightforward and the Rust additions mirror existing TypeScript logic.

The dynZeroEdgeRows map correctly handles the primary use case (call-expression decorator processed before bare decorator). A narrow gap exists: when a PTS-promoted dyn=0 edge is later encountered by a dyn=1+dynamicKind call, the upgrade won't fire because the PTS promotion path never writes into dynZeroEdgeRows. This won't affect the decorator scenario that motivated the fix, but it leaves the in-place upgrade logic incomplete for PTS-first resolutions.

src/domain/graph/builder/stages/build-edges.ts — specifically the PTS-upgrade branch (lines 1283–1294) and how it interacts with dynZeroEdgeRows.

Important Files Changed

Filename	Overview
src/domain/graph/builder/stages/build-edges.ts	Adds dynZeroEdgeRows map to track dyn=0 direct-call edges and upgrade them to dyn=1 when a later call carries an explicit dynamicKind; PTS-promoted dyn=0 edges are not enrolled in this map, leaving a narrow gap.
crates/codegraph-core/src/domain/graph/builder/stages/build_edges.rs	Adds RES-4 (Kotlin member callable reference pre-qualified lookup) and RES-3 (JVM reflection with literal key_expr) resolution steps to the native engine, mirroring existing WASM fallback logic. Logic is guarded by is_module_scoped_language to avoid JS/TS interference.
crates/codegraph-core/src/extractors/kotlin.rs	invoke calls on callable references now emit nothing instead of an unresolvable-dynamic synthetic node, matching WASM engine behaviour and eliminating a source of cross-engine divergence.

Sequence Diagram

%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
    participant C as buildFileCallEdges
    participant E as emitDirectCallEdgesForCall
    participant SE as seenCallEdges
    participant DZ as dynZeroEdgeRows
    participant ER as allEdgeRows

    Note over C: Call 1 — @Log() (dyn=0, no dynamicKind)
    C->>E: "isDynamic=0, hasDynamicKind=false"
    E->>SE: has(edgeKey)? → false
    E->>ER: "push([src,tgt,'calls',conf,0,'ts-native',null]) → idx=N"
    E->>SE: add(edgeKey)
    E->>DZ: set(edgeKey, N)

    Note over C: Call 2 — @Log (dyn=1, dynamicKind='reflection')
    C->>E: "isDynamic=1, hasDynamicKind=true"
    E->>SE: has(edgeKey)? → true
    E->>DZ: get(edgeKey)? → N
    E->>ER: "row[N][4] = 1  (upgrade dyn 0→1)"
    E->>DZ: delete(edgeKey)
    Note over ER: Edge now dyn=1 ✓

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
    participant C as buildFileCallEdges
    participant E as emitDirectCallEdgesForCall
    participant SE as seenCallEdges
    participant DZ as dynZeroEdgeRows
    participant ER as allEdgeRows

    Note over C: Call 1 — @Log() (dyn=0, no dynamicKind)
    C->>E: "isDynamic=0, hasDynamicKind=false"
    E->>SE: has(edgeKey)? → false
    E->>ER: "push([src,tgt,'calls',conf,0,'ts-native',null]) → idx=N"
    E->>SE: add(edgeKey)
    E->>DZ: set(edgeKey, N)

    Note over C: Call 2 — @Log (dyn=1, dynamicKind='reflection')
    C->>E: "isDynamic=1, hasDynamicKind=true"
    E->>SE: has(edgeKey)? → true
    E->>DZ: get(edgeKey)? → N
    E->>ER: "row[N][4] = 1  (upgrade dyn 0→1)"
    E->>DZ: delete(edgeKey)
    Note over ER: Edge now dyn=1 ✓

Loading

_{Reviews (1): Last reviewed commit: "fix(wasm): preserve dyn=1 when deduplica..." | Re-trigger Greptile}

[greptile-apps]

PTS-promoted dyn=0 edge not tracked in dynZeroEdgeRows

When a PTS edge is upgraded in-place to a direct-call edge with dyn=0 (lines 1283–1294), the key is moved from ptsEdgeRows to seenCallEdges but is never written into dynZeroEdgeRows. If a subsequent dyn=1+dynamicKind call arrives for the same source/target pair, dynZeroEdgeRows.get(edgeKey) returns undefined and the upgrade to dyn=1 is silently skipped, leaving the edge as dyn=0. The decorator case described in the PR (both calls resolved through the direct-call path) won't hit this, but a target that first appears via a PTS alias and later via a bare decorator would remain misclassified.

[github-actions]

Codegraph Impact Analysis

2 functions changed → 4 callers affected across 2 files

• emitDirectCallEdgesForCall in src/domain/graph/builder/stages/build-edges.ts:1235 (3 transitive callers)
• buildFileCallEdges in src/domain/graph/builder/stages/build-edges.ts:1545 (3 transitive callers)