bug: incremental rebuild produces different edge count than full rebuild

[carlos-alm]

Found during dogfooding v2.5.35-dev.26434e2

Severity: High
Command: codegraph build . (incremental after single-file change)

Reproduction

# Start from a clean full build
codegraph build . --no-incremental
codegraph stats --json  # => 1671 edges

# Modify one file
echo "// test" >> src/logger.js

# Incremental rebuild
codegraph build . --verbose
codegraph stats --json  # => different edge count (e.g., 2660 or 676)

# Full rebuild again
codegraph build . --no-incremental
codegraph stats --json  # => 1671 edges again

Expected behavior

After an incremental rebuild, the total edge count should match a full rebuild of the same codebase.

Actual behavior

Incremental rebuilds produce inconsistent edge counts:

• Full build: 912 nodes, 1671 edges
• After 1-file incremental: 912 nodes, 676 edges (verbose shows "912 nodes, 676 edges")
• The benchmark also shows this: oneFileRebuild consistently reports 676 edges vs 1671 for full build

The issue appears during the incremental path where only the changed file + reverse-deps are re-parsed. Old edges for files not in the re-parse set may be dropped or duplicated.

Root cause

The incremental rebuild re-parses a subset of files (changed + reverse-deps) but the edge insertion/cleanup logic may not correctly preserve edges from unchanged files. The "Graph built: 912 nodes, 676 edges" output likely reflects only the edges created in this incremental batch, not the total in the database.

The stats query after the build may also be affected — need to verify whether the DB actually has all edges or if they were dropped.

Impact

Users relying on incremental builds get a graph with fewer edges than expected, which could produce incomplete query results (missing callers/callees). This particularly affects CI workflows using diff-impact after incremental builds.