fix(pipeline): stable USAGE-edge ownership for directory-module languages (#787)

[spde]

What does this PR do?

Fixes #787: since #667, fresh indexes of the same Java tree attached USAGE edges to different (wrong) source files on every run.

Reproduce-first, per the triage note on the issue: the new tests/repro/repro_issue787.c asserts stable USAGE source ownership across repeated indexes — exact distinct-source set, 5 sequential re-indexes, and a >50-file variant that forces the parallel merge path. All three cases fail on unfixed HEAD (the parallel case surfaces a random filler file as a USAGE source, which is the race made visible).

Root cause

#667's directory-based Java/Go module QNs collide with the package's Folder node QN (or Project for root files), while every file still emits a Module def with that QN. Three code paths then corrupted source attribution on the shared node:

1. cbm_gbuf_upsert_node (graph_buffer.c) — the QA: reproduce-first bug suite + LSP/grammar extraction fixes (5-platform board green) #667 guard kept the Folder/Project label on a colliding Module def but still clobbered name/file_path/line-range, so the shared node's file_path became whichever same-package file was processed last.
2. merge_update_existing (graph_buffer.c) — the worker-gbuf merge had no guard at all: unconditional "src wins", including relabelling the Folder node to Module. Worker merge order varies per run — this is the nondeterminism.
3. The three source-node finders (find_enclosing_node / find_source_node / calls_find_source) look up class-level references' enclosing QN directly, landing on that one shared directory node — so all same-package class-level USAGE edges (e.g. @Autowired fields) collapsed onto a single source with an arbitrary file_path.

Fix

• Both graph-buffer paths now skip the update entirely when a Module def collides with a Folder/Project node (the merge path keeps the ID remap so worker edges still redirect to the canonical node).
• New cbm_pipeline_node_is_dir_container() predicate; the three finders treat a directory-container hit as a miss and fall through to the per-file File node.

Verification

• New repro: 3/3 green, stable across 10 consecutive runs (was 0/3 on HEAD).
• Full gating suite: 5748 passed, 0 failed.
• spring-petclinic, 3 independent fresh indexes: OwnerRepository inbound USAGE sources = exactly the 7 ground-truth files, identical every run (HEAD gave 4–6 with run-varying false positives).
• A private Spring Boot service (~1.3k Java files, 142 beans): grep-verified bean-user recall back to 757/757 = 100% (HEAD: ~16%).
• Incremental reindexing behavior from fix(pipeline): preserve inbound cross-file edges on incremental reindex #528 preserved (inbound USAGE survives an edit+reindex cycle).

Two adjacent direct enclosing-QN lookups were left out of scope (env-access CONFIGURES sources and resolve_file_throws); noted here rather than folded in, happy to follow up if you want them handled the same way.

[DeusData]

Thanks for the stable USAGE-edge ownership fix for #787. Triage: high-priority parsing correctness.

Review will focus on the reproduce-first fixture across repeated indexes and the graph-buffer merge/upsert changes. The important invariant is deterministic source ownership for directory-module languages without regressing the #667 package/module behavior.

[DeusData]

Thank you — this was a precise, well-diagnosed fix. All three mechanisms you identified (the label-only guard leaving name/file_path/props clobbered, the unguarded merge path, and class-level refs landing on the shared directory node) were verified exactly as you described, and your 3-part reproduction (exact source set / 5-run stability / >50-file parallel) was model reproduce-first work. We carried it over the line as 896aa91 (PR #844) with you credited as co-author — the only changes were adding DCO sign-off (your commits lacked the trailer) and one clang-format fix. Closes #787. Closing in favor of the distill — thanks again for the excellent write-up!