Incremental rebuild leaves stale blast-radius/fn-impact numbers for line-shifted declarations (same root cause as #1738, #1743)

[carlos-alm]

While validating phase 15 of the Titan pipeline (a pure ordering/dedup fix in src/db/connection.ts that inserts a new ~23-line helper function above several unrelated, unchanged declarations later in the file — shifting their line numbers but not their bodies), codegraph check --staged --blast-radius 30 reported a FAIL (maxFound: 46, violation on close at src/db/connection.ts:368) immediately after the file was edited (graph updated incrementally, presumably by the update-graph.sh post-edit hook).

Rebuilding the same staged state with codegraph build --no-incremental and re-running the identical codegraph check --staged --blast-radius 30 command produced a different, passing result: maxFound: 28. This was stable across repeated re-runs on the unchanged, cleanly-rebuilt state.

Root-cause hypothesis: this looks like the same incremental-staleness bug family already tracked as #1738 (stale codegraph structure directory metrics) and #1743 (stale cyclomatic-complexity values), but manifesting in a third subsystem: blast-radius / fn-impact / diff-impact computation. When a file changes such that unrelated, byte-identical declarations shift line numbers (e.g. inserting a new function above them), the incremental rebuild path appears to leave stale line-keyed edge/impact data for those declarations, producing an inflated and non-reproducible blast-radius count until a full (--no-incremental) rebuild is performed.

Reproduction:

1. In a repo with an existing graph.db, edit a file to insert N new lines of a self-contained function above several existing, otherwise-untouched functions (shifting their line numbers only).
2. Let the incremental rebuild run (e.g. via the post-edit hook, or codegraph build without --no-incremental).
3. Run codegraph check --staged --blast-radius <threshold> (or codegraph fn-impact <name>) against one of the shifted declarations — observe an inflated/incorrect blast-radius number.
4. Run codegraph build --no-incremental, then repeat step 3 — observe a different (correct, lower) number that is stable across repeated runs.

This is a real correctness bug in the incremental build path, not a documentation-worthy "acceptable gap" — filing per project policy that codegraph must produce correct results when analyzing itself.