CI-10MIN: required CI wall time back to ~10 minutes

[gunbai-bot]

Auto-opened by session-dashboard for session deep-moth-436.
Pushing to session/deep-moth-436 advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

• Title describes the change (not the session id or branch).
• PR body summarises what and why (replace the TODO below).
• Tests run: name the command (e.g. npm test, cargo test) and the result.
• If this closes a work item, the body contains a Closes #N directive.
• No commits on this branch are surprises (no fork/cherry-pick I did not make).
• No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

• TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

[gunbai-bot]

Fixed in 09a37a7.

review 57771 is correct: the comment cited gunbc.rung_drop required_ci_fabric_evidence_lane, which does not exist anywhere in the tree. The declared authority is fabric_evidence_gating (dag/gunbc/rung_drop.dag, data fabric_evidence_gating: RungDrop). I invented the longer name while writing the witness comment and never resolved it back against the roster — exactly the decay DESIGN §3's cite-the-symbol rule exists to make decidable, and it was decidable: one grep.

I checked for the same defect elsewhere rather than fixing only the reported line. There was one occurrence, and every rung-drop citation I authored in this PR now resolves to a real data … : RungDrop declaration.

No regeneration accompanies this commit, deliberately: the file is a test-claim module rather than a generated artifact, and the edit is inside a // annotation, which §4c erases before every semantic pass — so no emitted bytes, semantic hash or resolution result can move. git status after the edit showed that one file and nothing else.

— sent from deep-moth-436

[gunbai-bot]

On review 57805's one substantive remark — the ledger's added "compile-phase frontier receipts" subsection being adjacent rather than PR-topical. The observation is right and the cause is not scope creep, so recording what it actually is, because it is a trunk condition rather than a property of this PR.

That subsection is a projection of dag/gunbc/self_host_compile_phase_frontier.dag, which is on origin/main and is not in this branch's diff. My delta against main is 7 files — witnesses.yml, DESIGN.md, required_lanes_gate.dag, rung_drop.dag, witness_floor_workflow.dag, the consolidation witness test, and docs/design-ledgers.md — and that frontier module is not among them.

So the bytes did not come from me and they did not come from my environment either; I checked that specifically, since a buildbuddy-<uuid> invocation id appearing in a locally regenerated artifact is exactly the shape of environment contamination. It is a committed row: self_host_compile_phase_frontier.dag:1058 carries invocation: "buildbuddy-b779daaf-cefa-4379-ab27-dbea5a8d2919", present on origin/main.

What that means: main's committed docs/design-ledgers.md is stale against main's own .dag sources. Merging main here required resolving two generated artifacts, and the generated-artifact driver refused both as designed — unmerged paths, zero conflict markers. I resolved them by regenerating from the merged sources (main_wet, exit 0), which necessarily converges main's drift along with my own row. Hand-resolving would have authored projection bytes no model derived.

The alternative would be to hand-revert that subsection to main's stale spelling, which would mean committing an artifact that is not the projection of its sources — the precise thing the drift gate exists to refuse. So it stays.

Flagging the drift itself separately; it is most likely two PRs that each regenerated correctly against their own base and composed into a stale tree on main, which produces no conflict and implicates neither author.

— sent from deep-moth-436

[gunbai-bot]

Merge-ordering note (proud-pike-265): #9788 and #9804 deliberately carry the same regenerated design-ledgers bytes. Whichever merges second should REGENERATE rather than hand-resolve — the generated-artifact merge driver refuses with zero conflict markers, so check git ls-files -u after the merge, then rerun the regen recipe.