Disabled seven workflows that had never once been green

[gHashTag]

Seven workflows are now disabled_manually. Each had never produced a green
run and had not run at all in four months or more. Nothing was deleted, and
the state is reversible with one command per workflow.

workflow	lifetime runs	successes	last run
vibee-production-swarm.yml	98	0	2026-03-11
wave9-deploy.yml	1	0	2026-03-22
deploy-trinity-grid.yml	1	0	2026-03-30
fpga-hslm-bitstream.yml	11	0	2026-04-03
agent-mu-deploy.yml	35	0	2026-04-03
fpga-bitstream.yml	4	0	2026-04-03
benchmark-tests.yml	7	0	2026-04-03

Measured per workflow with:

gh api "repos/gHashTag/trinity/actions/workflows/<id>/runs?per_page=1"                --jq .total_count
gh api "repos/gHashTag/trinity/actions/workflows/<id>/runs?status=success&per_page=1" --jq .total_count

Deliberately left alone

Three dormant red workflows have succeeded before, so they are broken
rather than abandoned and deserve a fix, not a switch:

workflow	runs	successes
docker-agent.yml	36	30
hslm-docker.yml	33	12
fpga-docker.yml	13	4

Why

A gate that has never been green carries no information: red before your change
and red after it. Twenty-seven of them on main is not untidiness — it is the
measured reason a request path sat broken in nine places without anyone
noticing, including me, while I was the one selling the checks.

This does not fix anything. It removes seven permanent reds that could never
have been evidence of anything, so the remaining twenty can be read.

To undo

gh workflow enable <name>.yml --repo gHashTag/trinity

Any of them that turns out to matter should come back with a fix, so that
its first run under the new regime is one that can pass.

[gHashTag]

Two more, and they are a different category from the seven above — worth separating because the justification is not the same.

docker-agent.yml (36 runs, 30 successes) and hslm-docker.yml (33 runs, 12 successes) both used to work. They stopped because the things they build were deleted:

docker-agent  →  deploy/Dockerfile.agent exists, but it COPYs:
                   /deploy/agent-entrypoint.sh   — nowhere in the tree
                   /SOUL.md                      — only at docs/, templates/, apps/queen-web/

hslm-docker   →  ./deploy/Dockerfile.hslm-train  — does not exist at all

Diagnosed from a fresh dispatch, because the April logs had aged out of retention — a four-month-old red cannot be read, only re-run:

#13 ERROR: failed to calculate checksum of ref …: "/deploy/agent-entrypoint.sh": not found

No path fix recovers these: the entrypoint script is gone from the repository entirely, and so is the hslm-train Dockerfile. A workflow that builds an artefact whose sources were removed is not a broken check — it is a check with nothing left to check.

Both disabled. Same undo:

gh workflow enable docker-agent.yml --repo gHashTag/trinity
gh workflow enable hslm-docker.yml  --repo gHashTag/trinity

If either image is still wanted, what it needs is its missing source restored, and then the workflow back on — in that order, so its first run under the new regime is one that can pass.

fpga-docker.yml (13 runs, 4 successes) is left alone pending the same check.