feat(#6042): infer a community for unplaced changed entities, labelled as inferred

[cajasmota]

After #6006, conflicts mode declines when no changed entity can be placed in a community. Correct — with zero community signal any verdict would be invented — but useless for a completely ordinary PR shape: one that only adds code. A newly added entity is never in the group overlay, because the overlay comes from the last indexed group union and the entity did not exist then.

This infers a community for such entities from their overlay-placed neighbours, and labels every inference as an inference.

The rule: unanimity over at most two votes

• Container — entities sharing the new entity's SourceFile, plus any placed CONTAINS parent. CONTAINS was checked before being relied on: it is not a universal file→function edge (class→method, module→entity, produced ad hoc per language), so same-SourceFile is the load-bearing half.
• Module (Properties["module"]) — a strict fallback, voting only when the container abstains, with a sample floor (≥3) and a concentration floor (≥0.7).
• Call targets — allowlisted edge kinds only, requiring ≥2 placed targets. One edge is not evidence; everything calls a logger.

A community is inferred only when the votes are unanimous. Not inferred, deliberately: overlay-placed entities, removed entities, blast-radius entities, and chained inference — only overlay-placed entities vote, so inference cannot propagate across a new package or become order-dependent.

Review drove three structural corrections here, and each removed a class of wrongness rather than patching one:

Module is not independent evidence. The module histogram is a strict superset of the file histogram, because module.Derive is a pure function of SourceFile. Under the original 3/2/1 weighting, agreement counted one measurement twice at weight 5. Worse, module alone inferred on a bare plurality: a module with 51 placed entities split 26/25 produced a confident labelled placement. MarkerFileNames has no per-Go-package marker, so in a single-module Go repo everything under a top-level directory falls through to DefaultDepth = 2 and shares one label — meaning the most common add-only shape resolved against a large heterogeneous bucket. Now 26/51 declines, 9/10 infers, and both margins ride on the wire via CommunityInference{signals, support, sample}.

The strict-majority arithmetic was removed, not pinned. Once module became subordinate to the container, the 2*best > total comparison could never block anything — dead arithmetic that a surviving mutation had already shown nothing held. Unanimity over at most two votes makes the three-way split impossible rather than untested.

A container that abstains from contradiction must not fall through to module. Found while implementing the above: if a file's placed entities split 1-1, the module is a superset containing that same contradiction and resolves it only by dilution. containerVote now reports whether it had evidence at all, distinct from having no winner.

Provenance at every granularity below the verdict

The first version could ship a 100% manufactured conflict with community_data_inferred_only: false. Two refs with communities [3,7] and [9,7]: the 3 and 9 are measured, but 7 — the sole basis of the reported conflict — existed on both sides purely by inference. CommunityDataInferredOnly is a whole-verdict flag and says nothing about any individual pair. That is #6006's defect class one level down.

Now a community is inference-only when neither an overlay-placed changed entity nor a blast-radius entity puts it there — the blast radius counts as measured, since it is real edges to really-placed entities, pinned by its own test. That flows through ChangeImpact.InferredOnlyCommunities → MergeRiskPair.InferredSharedCommunities / InferredOnly → inferred_only_pair_count, plus per_ref[].inferred_communities (conflicts mode emits no changed_entities, so per-entity community_source was single-mode only) and a separate prose note that fires on a deduced pair even when the verdict flag is correctly false.

One inferred side marks the overlap. The first control-arm fixture asserted the opposite; the test was fixed rather than the code, because "these refs collide here" was never observed on that side.

Candidacy is overlay-absence, not a negative id

Inference originally triggered on communityID < 0, which includes the -2 sentinel written for entities that are in the overlay and which Louvain explicitly declined to place. This issue is about entities the partition has never seen. -2 is only ever written for present entities (overlay.go:165), so CommunityID == nil is exactly "never seen"; candidacy is now overlayAbsent(e).

#6006's negative-id test previously passed only because its fixture was a single entity with no file siblings, no module and no edges — a shape production essentially never produces, so it had quietly stopped covering production. Re-shaped: the entity now sits in a placed file, in a concentrated module, and calls two placed entities, so every signal fires and it must still be refused. Independently verified — widening candidacy to < 0 fails both that test and the new one.

Cost — the earlier figure is withdrawn

The first benchmark reported +0.61 ms. That fixture never inferred: its 1000 placed entities cycled over 5 communities in equal counts, so both histograms tied and both signals abstained. It timed the histogram build against a decline.

Rebuilt to assert inference fires before timing: 3.63 ms → 4.87 ms (+1.24 ms, +34%), +859 B, +13 allocs on 20k entities / 20k edges with a one-entity add-only change. Still ~0.4% of a cold call against the memoized 326 ms / 76 MB overlay parse, and nothing is built when every changed entity is already placed.

Verification

34 mutations, all killed by real test failures — the battery was rebuilt from scratch against the final tree rather than carried forward, and that mattered: one mutation initially survived (the decline message losing its inference sentence, where the first attempt removed only one of two clauses) and one earlier "kill" turned out to be a build failure rather than a test failure. Both corrected and re-run.

The battery permanently includes the four that survived review: the tied-only guard, the missing edge-kind filter, and deleting community_data_note / refs_with_inferred_community_data.

minPlacedTargets=1 still fails TestAnalyzePRImpact_AvailabilityFollowsChangedSetNotEntitySet, confirming #6006 binds — and since it binds through that constant, the mutation is now permanent in the battery.

go build ./... && go vet ./... && gofmt -l . clean. internal/graph/... and internal/mcp green post-rebase, raw exit 0 via rtk proxy.

Known and disclosed

Unanimity makes container-vs-targets disagreement decline where the old weighting inferred the container, so the inference rate is lower than the first version implied. Most add-only PRs into existing directories are still expected to infer, but that is not measured on a live corpus and no number is claimed.

Blast-radius entities are not inferred, so blast_radius_hit slightly understates communities on add-heavy PRs. The tool description is capped at 80 chars by budget_test.go, so the inference contract lives in the payload only.

Independently adversarially reviewed.

Closes #6042