Fix fleet main-red: jobserver anchor under §3 nickname → canonical extdeps_external_authority_anchor

[gunbai-bot]

Fleet main-red fix: jobserver anchor declared under a §3 nickname

Symptom (on main). The anchor-completeness floor witnesses are RED on current main:
corpus_live_anchored_modules_clean_holds / corpus_live_clean_tree_holds (= extdeps_external_authority_live_clean_tree_holds()) and the extdeps_external_authority_gate. One drifted module reds the gate fleet-wide, so every PR's floor batch-2 inherits this red.

Root cause (by execution). The live anchor roster is derived_extdeps_module_paths() = build_module_path_index() keys under extdeps. — a static source-tree index. For each module, project_external_authority_anchor reads only a data decl named extdeps_external_authority_anchor (read_external_authority_anchor_from_items, extdeps_shape_transport_policy_project.rs:578). extdeps.ctrl.jobserver (added new in #5663) declared its ExternalAuthority under the nickname ctrl_jobserver_authority instead of the canonical single-authority name every sibling uses (e.g. extdeps.git). So it projects Absent → live_violation_module_paths() = ["missing:extdeps.ctrl.jobserver"] → gate red. It is the sole violation (verified: full-tree projection-replica scan over dsl/extdeps/** + src/v2/extdeps/** shows exactly one unanchored live module before this fix, zero after).

This is a §3 single-authority violation (a nickname for a concept that already has one canonical name) — not #5670 (a v1-interpreter runtime service-op change that never touches the static roster).

Fix. Rename the decl to the canonical extdeps_external_authority_anchor (1 line). No consumers — the decl was referenced only at its own declaration site. The Https scheme + github.com/... locator were already valid; only the decl name the projection keys on was wrong.

Verification (by execution).

• Projection-replica tree scan after fix: zero unanchored live extdeps modules.
• Host test external_authority_live_clean_tree_holds_via_host (runs the exact host projection over the fixed tree): green + roster count > 150.

Follow-ups (not in this hotfix):

• Merge-skew note: STAGE-2 PR-1: fleet-resource model (per-type baselines + shared build pool) + §3 jobserver single-authority #5663 merged ~20:49Z, just after the concurrent §2A drift fleet-red (Fix fleet-red drift: derive §2A census from .dag authority (structured rows) #5671, 20:26Z). The leading hypothesis is that STAGE-2 PR-1: fleet-resource model (per-type baselines + shared build pool) + §3 jobserver single-authority #5663's own new anchor red was masked by the concurrent fleet-red (or a stale-binary local check), so it merged with a latent red that surfaced once the fleet cleared. This is exactly what A1's Wall A (re-run the floor on the merge-RESULT tree) catches.
• Construction hardening (separate PR): the anchor projection keys on a magic decl name — itself a name-keyed single point a new module can silently violate (jobserver did). Keying on the type (: ExternalAuthority) instead would make the nickname-violation unwritable, or a fail-closed authoring-time diagnostic should name it. Same name-keyed-fail-open family as the resolver collision wall.

🤖 Generated with Claude Code

[gunbai-bot]

Superseded — closing as redundant. The jobserver anchor §3-fix this PR carried (ctrl_jobserver_authority → extdeps_external_authority_anchor) ALREADY LANDED ON MAIN via #5687 (5dbf840, commit msg: 'Fix main-red extdeps_external_authority_gate: jobserver anchor name'). dsl/extdeps/ctrl/jobserver.dag on this branch is now byte-identical to main; the only remaining diff vs main is stale-behind (#5682/#5664 not yet merged in). Nothing to merge. The anchor-completeness main-red (corpus_live_anchored_modules_clean / extdeps_external_authority_gate) is resolved on main. The separate #5682 ROADMAP drift is also resolved on main via #5688 (fe36970).