Reduce unresolved graph edges: dataflow placeholder binding + lone-method guard

[zzet]

Problem

A data-driven pass over the unresolved edges in a Go repo's graph found the dominant class isn't stdlib/external noise — it's the dataflow / CPG layer. Store-wide, ~46% of all arg_of edges point at unresolved:: placeholders,
and the large majority of those have both endpoints unresolved — dangling placeholder→placeholder hops such as arg_of: unresolved::contractFields → unresolved::newGCX, where both are real functions defined in the same file.

These edges do double damage: they bloat the resolver's pending set (every one is re-examined on every full pass), and they break flow_between / taint across the hop because neither end points at a real node.

Root cause: resolveEdge only ever rewrites e.To, and it lifts a bare-name callee via the From node's repo prefix. A dataflow edge's From is an unresolved:: argument placeholder with no node, so the candidate lookup is scoped to the empty repo, matches nothing in a multi-repo graph, and the callee never lifts. materializeDataflowParams then skips the edge because its target is still an unresolved:: stub. Go-builtin attribution fails the same way — it gates on the From node's language.

Fix

• bindDataflowCalleeRefs (new internal/resolver/dataflow_callee_bind.go): a cheap post-resolve pass that binds arg_of / value_flow bare-name callees to the sole same-file function/method via a prebuilt file → name index (O(1) per edge). It matches by FilePath equality, so it needs no repo-prefix logic and behaves identically in bare and prefixed graphs, and it runs in the attribution tail rather than the hot per-edge loop.
• Builtin-arg attribution: fall back to the .go file extension when the From placeholder can't be classified, so append / make / len arguments attribute to their builtin node.
• Uniform repo prefixing: IndexRepo now always stamps the repo prefix, matching the cold-index path — a repo is prefixed from its first index and adding another is purely additive, instead of a lossy bare→prefixed rewrite.
• Observability: per-sub-phase resolve timing, a pending-edge shape breakdown, and unconditional per-sub-pass logging for the global graph passes (which previously ran silent for minutes on a cold index).

Measured (Go repo, cold index)

metric	before	after
arg_of-unresolved	59,939	10,300 (−83%)
dataflow-unresolved (arg_of+value_flow)	63,987	12,325 (−81%)
arg_of into builtins remaining	~14,800	0
resolve compute_loop	241s	296s (unchanged; within run variance)

Remaining (out of scope for this change)

• ~7.8k arg_of to *.method / qualified targets — need the receiver-type method resolver, a separate change.
• ~2.5k callees defined in the same package but a different file — this pass is same-file only, to keep incremental == full-index convergence trivial.

Note on the prefixing change

New and existing prefixed stores are consistent; an existing bare single-repo store would want a one-time cold re-index (the prefix-scoped eviction won't clear bare rows). The daemon's cold-index path already prefixes unconditionally, so this closes a latent inconsistency rather than migrating live data.

---

Follow-up: keep lone in-repo method binds against the cross-package guard

While tracing the remaining *.method dataflow residual, the biggest cause turned out to be upstream: the method calls themselves don't resolve, so there's nothing for the dataflow join to point at. A large, cleanly-fixable slice of that is a guard bug: a method call carries its receiver and needs no import of the method's package, but the cross-package guard reverted a lone-method bind whose package the caller doesn't directly import (a receiver returned from elsewhere, an embedded/inherited method). The lone-member-definition exception that already protects Java is generalized to Go (member calls only; a bare free-function call to an un-imported package still reverts; gated on a known receiver type naming an in-repo type).

Result on a Go repo: unique-name member calls left unresolved 3,366 → 85 (−97%), no change to resolve time. What remains is genuinely upstream — ~9k calls to methods with no in-repo definition (interface / embedded / external) and ~1.4k ambiguous names that need real receiver-type inference.

---

Follow-up: cut resolve wall-time with an indexed edge-liveness lookup

Profiling the cold/full resolve pass found that ~40% of resolve CPU — and most
of its GC churn — went to a single yes/no question. The chunked apply loop and
the cross-package guard call edgeStillLive once per applied edge to confirm an
interleaving edit hasn't evicted the row; on a sqlite-backed daemon that ran
GetOutEdges, which materialises and gob-decodes every one of the From node's
out-edges just to compare five fields.

Store.EdgeExists answers it as a single point lookup on the edges UNIQUE (from,to,kind,file_path,line) index — no row decode, no Meta blob, no per-edge
allocation. edgeStillLive uses it via an optional interface and keeps the
out-edge scan as a fallback for the in-memory graph. Same predicate, same result
(the value-match branch is exactly what fired on sqlite; the pointer test never
matched a freshly-decoded row), so every resolved edge is byte-identical —
reindex_batch is 557,072 before and after.

metric (4-repo cold index)	before	after
ResolveAll total	552s	159s (−71%)
cross-package guard	283s	11s (−96%)
compute + apply loop	241s	34s (−86%)
edgeStillLive share of resolve CPU	40.3%	4.6%
resolved edges (reindex_batch)	557,072	557,072 (identical)