Complete the deploy-workflow root cut: delete the authority, not just the file

[gunbai-bot]

The problem this fixes

#8676 deleted .github/workflows/deploy.yml under the operator's unclear-ownership ruling. It removed the projection and left the authority that writes it. Measured on clean main:

gunbc run --entry dag/tools/generated_artifact_gate.dag --function main_wet
  -> [file] write .github/workflows/deploy.yml (2050 bytes)

It comes back, with the ungated git push origin "$GITHUB_SHA:$DESIRED_REF" intact — no lease on the create branch.

That isn't drift. It's the surviving authority faithfully reversing an operator decision, and nothing detects it: DESIGN.md records the generated-artifact drift gates as unguarded after the floor cut, so neither the re-addition nor the absence is caught. The next person to regenerate would have silently re-added a deleted file, looking like unrelated churn in their diff.

Deleted

dag/gunbc/live_deploy_workflow.dag	the module that rebuilds it
LiveDeployYamlArtifact	variant, roster, path, commit policy, eq, emit arms
dag/test/claim/live_deploy_workflow_witness_test.dag	witnesses for a deleted workflow
gunbc_ci_advance_fleet_desired_script	+ its Scaffold disposition and dissolution trigger
the deploy.yml line in generated .gitattributes
an orphaned fleet_desired_ref_name import in ci_spec

The advance script is not preserved for a future actuator. Its only two consumers were the two deleted files, and gunbc.fleet_desired_admission (#8643) is the admitted replacement — it advances the ref only behind a modeled decision over a completed floor run, rendering the push from typed values rather than $GITHUB_SHA. Keeping a function that still emits the raw form would leave the unsafe spelling one call site from returning, which is the same leaf-versus-root error this PR corrects.

Preserved, deliberately

gunbc.live_deploy.{spec,apply,emit,readiness,…} and live_deploy_apply_srv1_wet stay. They describe and realize a deployment and could back a future fleet-convergence member; they are not what recreates the workflow. Deleting them would widen an operator decision about one file into retiring the deployment concept itself.

Evidence, on a clean checkout

LiveDeployYamlArtifact                     0 live references
expected_deploy_yml                        0 live references
gunbc.live_deploy_workflow                 0 live references
gunbc_ci_advance_fleet_desired_script      0 live references
.github/workflows/deploy.yml               absent after main_wet
deploy line in .gitattributes              absent
second main_wet                            no diff (idempotent)

The retirement witness, and its control

Absence cannot be evidence of itself — that is exactly how the first deletion failed. One witness makes it executable:

	roster as committed	path re-added
..._is_not_in_the_committed_artifact_roster	PASS	FAIL
the_roster_is_populated_and_still_carries_the_surviving_workflow	PASS	PASS

The red arm was produced by repointing an unrelated artifact at the retired path, so the claim triggers on the path returning under any variant, not on a particular variant name. The companion claim asserts the roster is populated and still carries witnesses.yml, so the negative is a statement about deploy.yml rather than about an empty read — an empty list satisfies every "does not contain" assertion.

Worth noting what the first red attempt found instead: adding a new variant refuses at compile time with non-exhaustive match: missing variant(s). The substrate already walls incomplete row additions; what it does not wall is an existing row silently pointing at a retired path.

This is not a replacement registry or a substitute authority. It retires when the drift gates come back off the re-add queue and enforce roster membership in both directions.