fix(graph): key IMPORTS edge dedup on local_name, not just source/target

[apappas1129]

What does this PR do?

Closes #768: a single import { A, B } from './lib' statement produced exactly
one IMPORTS edge instead of two — whichever symbol got written second
silently overwrote the first.

cbm_gbuf_insert_edge() (src/graph_buffer/graph_buffer.c) dedups edges on
(source_id, target_id, type) only. Two named imports from the same specifier
resolve to the same (source_file, target_file) pair, so the second
IMPORTS edge collides with the first on that key. On collision the function
doesn't merge or reject — it replaces properties_json outright (the
existing /* Merge properties (just replace for now) */ comment suggests
this was a known stub).

This has a bigger blast radius than "who imports X" queries: pass_calls.c,
pass_usages.c, pass_semantic.c, and pass_lsp_cross.c all build their
local_name -> resolved module QN maps for cross-file call resolution by
parsing exactly one local_name out of each IMPORTS edge's properties. So
the dropped symbol's calls also failed to resolve cross-file, not just the
import edge itself.

make_edge_key() now folds local_name into the dedup key specifically for
IMPORTS edges, so two different symbols imported from the same specifier
become two distinct edges. A re-inserted identical import (e.g. an idempotent
re-index) still dedups to one edge. No changes were needed in any of the four
downstream consumers — they already iterate edges and parse one local_name
per edge; they simply see both edges now that dedup stops collapsing them.
Other edge types (CALLS, HTTP_CALLS, DEFINES, ...) keep their original
(source, target, type) key, unchanged.

Checklist

• Every commit is signed off (git commit -s)
• Tests pass locally (make -f Makefile.cbm test) — full suite green
  except one pre-existing, unrelated RSS-ceiling test in
  test_incremental.c (~2.6GB vs 2048MB limit) on this machine
• Lint passes (make -f Makefile.cbm lint-ci) — could not verify
  locally, cppcheck/clang-format are not installed in this
  environment; relying on CI
• New behavior is covered by a test: added gbuf_imports_multi_symbol_dedup
  in tests/test_graph_buffer.c, asserting two same-target imports with
  different local_name produce distinct edges while a repeated
  identical import still dedups to one

[DeusData]

Thanks for the IMPORTS dedup fix for #768. Triage: parsing/import graph correctness.

Review will focus on whether edge identity including local_name is sufficient without surprising other edge types, and whether the tests cover multiple named imports from the same specifier plus existing consumers of edge dedup behavior.

[DeusData]

Thank you — the diagnosis is exactly right (main keys IMPORTS dedup on (src,tgt,type) and silently replaces properties, dropping sibling imports and breaking downstream local_name consumers), and your gbuf test is a genuine red-first guard at that tier. One blocking completeness issue we found while verifying end-to-end: the edge-uniqueness contract lives in three places, and this PR changes only one. Both persistence paths still declare UNIQUE(source_id, target_id, type) — the runtime store (store.c DDL + the ON CONFLICT upsert) and the raw dump writer (which emits that DDL and hand-builds the unique autoindex mechanically from all edges). With this change alone, any repo containing import { A, B } from './x' produces a DB that violates its own declared unique constraint — PRAGMA integrity_check reports non-unique index entries, and later upserts against that pair have ambiguous semantics. (CI stayed green only because no fixture has a multi-symbol import.) Could you extend the PR to change the contract coherently in all three places — e.g. include local_name in IMPORTS uniqueness or redefine the index — plus one end-to-end test: index a two-symbol import, dump, run integrity_check, query both edges back? Also worth bumping EDGE_KEY_BUF or documenting the truncation behavior for very long local names. With that, this is a clean merge — thanks again for the excellent issue write-up.

---

Update: to keep momentum on the bug backlog, we're going to carry the changes above over the line ourselves shortly — a distilled follow-up on current main implementing the notes in this thread, with you credited as Co-authored-by on the commit, and this PR closed referencing it. If you'd prefer to push the update yourself, just reply within the next couple of days and we'll gladly take yours instead. Thanks again for the contribution!

[DeusData]

Thank you — your diagnosis was exactly right (dedup keyed on (src,tgt,type) silently replacing properties and dropping sibling imports), and your gbuf test was a genuine red-first guard at that tier. While verifying end-to-end we found the uniqueness contract lives in three places (graph buffer key, the store's UNIQUE DDL + upsert conflict target, and the raw dump writer's hand-built autoindex) — changing only one ships DBs that violate their own declared constraint, so we carried your fix over the line with the other two sites co-updated, a schema-compat probe for older DBs, and an end-to-end integrity_check test, crediting you as co-author. Merged as 541ff61 (PR #814), closing #768. Closing this in favor of the distill — your issue write-ups on this series (#767, #768, #730) have been a genuine pleasure to work with. Thanks again!