fix(graph_buffer): merge duplicate-edge properties commutatively

[Studnicky]

Fixes #1469

What does this PR do?

On a duplicate edge key, cbm_gbuf_insert_edge replaced the stored property blob unconditionally ("just replace for now"). confidence, strategy and via are not part of the dedup key, and per-worker edge buffers merge in worker-slot order, so which strategy's attributes survived was a function of thread scheduling.

This replaces the overwrite with a total order over the two candidates, making the merge commutative and associative and therefore independent of arrival order:

1. higher confidence wins, which also enforces the intended precedence that an LSP-resolved call outranks a textual match;
2. on equal confidence, the lexicographically greater blob wins, giving a deterministic choice between otherwise equal candidates.

An empty or absent incoming blob still never displaces stored properties.

Why

Duplicates carrying different attributes genuinely occur — pass_calls mints CALLS edges from both LSP resolution and registry-textual matching. The edge set was stable while its attributes flickered run to run, so an MCP consumer reading CALLS confidence could see a different value for the same commit across two indexes of the same tree.

It also means the precedence pass_parallel.c documents — "LSP-resolved calls take precedence over registry-textual matching" — was only honoured when the LSP edge happened to arrive second. Under this rule it holds regardless of arrival.

The node path already works this way: cbm_gbuf_upsert_node picks the survivor of a same-QN collision by a canonical content rule "so the pick is commutative and scheduling-free" (#923). This applies the same idea to edge attributes.

Testing

Three new tests in test_graph_buffer.c:

• gbuf_edge_props_merge_is_order_independent — the same pair of blobs inserted in both orders must leave identical stored properties.
• gbuf_edge_props_merge_prefers_higher_confidence — the higher-confidence blob wins even when it arrives first.
• gbuf_edge_props_merge_keeps_existing_on_empty — guards the {} case.

The first two fail on an unpatched tree (51 passed, 2 failed), with the low-confidence registry blob having overwritten the high-confidence LSP one. All three pass with the change.

scripts/test.sh: 438 passed across graph_buffer configlink simhash semantic parallel pipeline. The full suite matches the pre-change baseline exactly — the two failures (cli, py_lsp_scale) reproduce identically on an unpatched tree.

scripts/lint.sh: no new findings. graph_buffer.c reports the same 8 pre-existing items as before the change.

Note this is invisible to tests/repro/repro_parallel_determinism.c, which compares (source_qn, type, target_qn) triples and so cannot observe attribute churn — hence unit coverage rather than a corpus repro.

Risks

Edge identity and edge count are unchanged; only which blob survives on a duplicate key differs. Where duplicates disagreed, the stored attributes may now differ from a given previous run — but previously that value was scheduling-dependent, so there was no stable prior value to preserve.

edge_props_confidence parses "confidence": with strtod; a blob without one reads as -1.0, so any edge stating a confidence outranks one that does not. Blobs that carry no confidence at all fall through to the lexicographic tie-break, which is deterministic but arbitrary — deliberately, since there is no semantic basis to prefer either.

Scope is limited to the duplicate-key path in cbm_gbuf_insert_edge; the key format, the store schema, and the MCP surface are untouched.

Links

• Fixes graph_buffer: duplicate-edge property merge is last-write-wins, so edge attributes depend on worker merge order #1469
• Canonical-content precedent on the node path: fix: graph-buffer upsert contract + mem budget poisoning (4 red tests) #923
• Related determinism work: pass_semantic_edges: SEMANTICALLY_RELATED edges are nondeterministic across identical runs (~50% churn) #998, perf: kernel-scale indexing campaign (-61% wall, deterministic output) #921

Checklist

• Every commit is signed off (git commit -s)
• Tests pass locally
• Lint passes
• New behavior is covered by a test (reproduce-first: two of the three are red on an unpatched tree)

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Merged — thank you @Studnicky. The key insight is the one most fixes in this area miss: making the merge a total order (confidence, then lexicographic) rather than picking a "better" arrival makes it commutative and associative by construction, so worker scheduling cannot influence the outcome. And it doubles as the precedence rule we actually want — an LSP-resolved edge outranks a textual match. The both-orders test is exactly the right shape.

This feeds directly into a known issue we have had open since the 0.9.1 RC: node counts are byte-stable across runs but edge totals drift 0.01–1.3% on resolution-heavy languages. Non-key edge attributes being decided by merge order is one concrete source of that, now closed.