fix(detection): resolve same-extension collisions by sibling content (#3137, closes #3132)

[squid-protocol]

What

Ecosystem gravity resolved a neighbourhood by counting extensions. For a same-extension collision that is information-free by construction: both rivals score over the identical set of contested-extension files, so the base-mass fallback counts the same files for each, and the only tie-breaker left is a discriminators self-reference — python lists its own .py, which is literally where the reported "72% Local Dominance" came from (python base 14 + 14×2 = 42 vs embedded_python's 14 + 1×2 = 16).

This adds a sibling-classification vote (#3137): when a neighbourhood carries no different extension-shaped ecosystem anchor — the exact regime where extension counting is blind — gravity now weighs what the siblings actually resolved to via their own content (shebang / internal discriminator), not their filenames. A sibling that classified as embedded_python because it imports machine is real evidence about its neighbours; a sibling that merely shares the contested extension is not evidence and casts no vote. An empty or split neighbourhood abstains to Tier 3 rather than letting max() iteration order pick a winner (the #3118 silent order-dependence).

The mixed-extension neighbourhoods gravity was built for — .h beside .c, .asm beside .jcl/.cbl — carry a real cross-extension signal and keep the extension-count physics untouched.

Why this is the fix #3132 needed

#3132's residual 4 files (diagnostics.py, logging.py, meowprotocol.py, tester.py) import nothing MicroPython-specific and are genuinely indistinguishable per-file — the exact case neighbourhood context exists to solve. Its comment thread measured three cheap fixes and all three lost (abstain → 32 sqlite files fall to db2_sql; strip the contested ext from discriminators → same loss; remove only python's .py self-reference → breaks 7 plain-python files). This is the "weigh sibling classifications, not extension counts" change #3137 asked for, which those cheap versions could not substitute for.

Closes #3137. Closes #3132.

Measured (#3117 detection-accuracy harness, pinned language-crucible)

metric	before	after
determinable accuracy	3226/3231 = 0.9985	3231/3231 = 1.0 (Objective 1 MET)
ambiguous rejection	1/1 = 1.0	1/1 = 1.0 (unchanged)
confusion pairs	{embedded_python→python: 4}	none

No regressions on the previously-correct contested extensions: sqlite (n=76), matlab, objective-c, rexx, python (n=269) all stay at precision/recall 1.0. The one deterministic property that makes this safe: sqlite has no content signal, so its .sql files cast no vote and the neighbourhood abstains to the untouched physics — sqlite is resolved exactly as before.

Why is this cheap to trust? Any file that reaches gravity has already failed content resolution (a Tier 2 internal-discriminator match locks at tier 2 and never calls gravity), so the neighbourhood verdict is independent of which sibling triggered it — the vote is memoised once per directory+extension and is deterministic.

Golden masters

Reblessed both golden_master_audit.json (full-precision) and golden_master_zero_dep_audit.json (zero-dep). The drift is exactly the 4 intended language corrections (python → embedded_python) plus their downstream metric/proof changes; zero language flips anywhere else in the 3,531-file corpus. tests/detection_accuracy_baseline.json re-pinned to the new 1.0 numbers (also drops a stale hlasm→assembly entry that current main no longer produces).

🤖 Generated with Claude Code

[github-actions]

🐦‍⬛ Muninn Security Scan

✅ No security issues found.

🐦‍⬛ Powered by Muninn · Skald Lab