Name the bare-read authority in three extdeps modules, and admit the one leaf it narrows

[gunbai-bot]

Extracted from #11193 on sunny-carp-329's ruling: "the import fix + its admission row land as their own PR, and I delete the row immediately after. Do not couple main-blocking debt to a PR that is blocked." #11193 was blocked at the time of that ruling; the reason it must not carry main-blocking debt is unchanged by what has since unblocked it.

⚠️ LANDING DEBT — owner: sunny-carp-329

NAMESPACE_TRANSITION_ADMISSIONS admits exactly the deltas it rosters, and a rostered row with no corresponding live delta refuses. The row this PR adds is consumed the moment this lands: main's push refuses until the row is deleted.

sunny-carp-329 is the payer for that deletion. It is step 3 of their four-step sequence and is not a task for whoever next touches namespace_wave_admission.rs.

What this changes

Three modules read a name bare that resolves to more than one declaration, and the AmbiguousBareNameRead wall refuses them. The repair the wall prescribes is to name the authority in the import.

module	bare read	import added / narrowed
extdeps.realization.artifact_store_fs	Filesystem	import extdeps.filesystem.filesystem_io { Filesystem } (was brace-less)
extdeps.bmc.ipmi	String	import std.string_type { String }
extdeps.cron	String	import std.string_type { String }

The Filesystem choice is derived from the usage, not guessed: filesystem_io is the only module in the closure that admits it.

Why there is a namespace delta at all

A brace-less import binds nothing for the refused name and widens every leaf in the module's candidate sets. Naming Filesystem therefore also removed filesystem_io's own extdeps_external_authority_anchor from that leaf's candidates — one TargetChanged delta on extdeps.realization.artifact_store_fs. It is a consequence of the prescribed repair, not a second change riding along.

The row's comment carries the reasoning for why this does not change which declaration any spelling denotes: the spelling occurs exactly once in that module — its own data declaration — and nothing in the closure reads it. Neither importer imports the anchor; the only other corpus references to that leaf are a decl_name string in std.citation and a different module's anchor. So the base two-candidate set sat at a declaration site with no reference: there was no denotation to move, only a candidate count a brace-less import had inflated.

What this PR deliberately does not claim: which candidate the base resolution picked. The two declarations differ materially (this module's anchor cites the repository's own dag/extdeps/realization tree; filesystem_io's cites the POSIX write specification), so had anything referenced the leaf, that question would need the resolver run rather than reasoned about. Nothing references it, so it does not arise.

Evidence

• cargo check -p v1-compiler --lib — clean (exit 0, Finished dev profile), private CARGO_TARGET_DIR
• cargo fmt --all --check — clean (pre-commit hook)
• corpus compile-clean gate: 0 blocking errors, 784 advisory (policy gunbc.compile_clean_diagnostic_policy)

🤖 Generated with Claude Code

https://claude.ai/code/session_018oRuEWKyaADAAkinhP6acP