Refuse a module-filename collision instead of silently overwriting the emitted file

[gunbai-bot]

v1.compiler.emit_core_support module_to_filename maps '.' to '_', which is
MANY-TO-ONE: a.b_c and a_b.c both render a_b_c. Every target emitter names
one emitted file per module by that mapping, so two colliding modules wrote the
same path and whichever was emitted second silently replaced the first — a wrong
artifact with no diagnostic anywhere.

MEASUREMENT FIRST. Across dag, src/v1 and src/v2 there are 4187 distinct
authored module names and 4187 distinct filenames under the mapping: zero
collisions today. That is luck rather than structure — 3537 of the 4187 names
already contain an underscore, so the surface the mapping is many-to-one over is
most of the corpus. The wall therefore lands green over the live tree and is not
a ratchet against existing debt.

THE REFUSAL. The mapping cannot be made injective without changing every emitted
path and every cross-module reference derived from one, so the residue is refused
rather than absorbed (DESIGN.md §5 — a failure arm refuses, never widens).
module_filename_collision_diagnostics folds the whole module population once
and returns one located ModuleFilenameCollision per colliding pair, naming the
filename and both modules. It is called by emit_rust, emit_python and
emit_go before any file is produced, because the collision is a fact about the
module set and not about any one target's rendering.

ModuleFilenameCollision is a new CompilerDiagnostic variant. Both total
matches over that coproduct in 00_core.dag gain an arm, and its two
hand-maintained seed projections in cli_run.rs (the histogram key and the
subject-name extractor) gain the mechanical arm each, per the receipt in
compiler_diagnostic_seed_projection_note. It is blocking by default — no
advisory-allowlist entry is owed.

EVIDENCE, BY EXECUTION. dag/test/claim/module_filename_collision_witness_test.dag
uses tools.multi_module_compile_fixture, because the subject IS a relationship
between two modules and no single-module census can express it. The
discriminating RED compiles mmfc.a_b + mmfc_a.b and asserts a BLOCKING row of
class ModuleFilenameCollision — naming the class, not merely "something
refused". The positive control renames one segment so the filenames differ and
asserts zero diagnostics of ANY severity. Both were executed on this branch's
compiler and returned true.

The five regenerated stage0 mirrors are the emitter's own output:
claim_executor --required-regen reports first_generation_equal=true.

Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
🤖 Generated with Claude Code

[gunbai-bot]

Addressed the REQUEST_CHANGES from review 56887 in 113269e.

The finding was correct: compiler_diagnostic_seed_projection_note ends with the DuplicateDeclaration lane and explicitly requires the next lane to re-measure, and this PR expanded the seed without doing so. The note now carries a FOURTH LANE clause with the three commands the receipt itself names, re-run against origin/main 9538523:

• grep -cE "^(pub )?fn " src/v1/stage0/src/cli_run.rs — 896 at origin/main, 896 on this branch. The carrier census is FLAT: no new hand-Rust function.
• git diff --numstat origin/main -- src/v1/stage0/src/cli_run.rs — 2 added, 0 removed.
• git diff origin/main -- src/v1/stage0/src/cli_run.rs | grep -cE "^\+.*\bfn " — 0 added fn declarations.

Two things the clause states rather than leaves to inference. The prior lane recorded 8 changed lines against a base of 890 and this one records 2 against 896; the difference is rustfmt wrapping of a wider variant pattern, not added capability, and the prior lane figures are left untouched rather than amended. And ModuleFilenameCollision is a blocking diagnostic, so the advisory-allowlist obligation the note carries for advisory variants does not fire here.

Dissolution: the clause inherits the existing ROADMAP row v1-zero-hand-maintained-rust (referenced from dag/test/claim/roadmap_authority_test.dag) rather than minting a fresh trigger — these two arms are projection rows in the same carrier that row already governs, and a per-lane trigger beside it would be a second authority for one fact.

v1_std_core.rs regenerated from the amended note; claim_executor --required-regen reports first_generation_equal=true over 138/138.

Also merged origin/main to pick up #9497. The required floor is currently red on two findings in files this PR does not touch — dag/product/fabric/contention.dag imports grant_duration_seconds, which #9397 renamed on main and did not update the caller for. That break is owned by #9488 and is not mine to repair.

— sent from deep-bear-239

[gunbai-bot]

Thanks — on the grouping nit from review 56913, declining, with the reasoning stated so it can be overridden.

For three modules a, b, c that render one filename, the fold reports [a, b] and [a, c]: two blocking rows rather than one [a, b, c]. Both rows are true, both name the shared filename, and both name a real pair that cannot coexist. The line stops either way.

Grouping is representable — modules is already a List<String> — but it costs a second pass over the owner map to collect classes before emitting, and it buys a presentational improvement in a case the live corpus does not contain: measured over the current tree, 4187 distinct module names render 4187 distinct filenames, so the collision population is zero and the three-way sub-population is a subset of that. Against a zero population I would rather not add a pass whose only effect is grouping, and the seed regeneration it would require is ~25 minutes of build and verify for that.

The one thing I would change my mind on is if the pairwise form were misleading rather than merely ungrouped — if a reader could repair [a, b], re-run, and be surprised by [a, c]. That is real, but it is the correct behaviour for this wall: renaming b genuinely does not resolve c, and a reader who saw one grouped row would still have to make two renames. The second diagnostic is the second obligation, not a repeat of the first.

Recorded here rather than in the carrier because it is a diagnostic-quality preference and not an invariant.

— sent from deep-bear-239