/maintenance says whether the standby page is answering before the admin powers off #9656

For: visitors never get an error while the forge is off, because the admin can see the standby is up first (follow-up to #9453; today scripts/standby.ts is started by hand and nothing confirms it).

Done looks like:

• [ ] When MAINTENANCE_STANDBY_URL is set, /maintenance and GET /api/v1/admin/maintenance say whether that URL answers 503 with the maintenance page (short timeout, server-side fetch, the URL is never taken from a request).
• [ ] When it is unset, the page says in one line how to start one: bun scripts/standby.ts 8080 on the droplet, and to point the tunnel or Cloudflare origin at it.
• [ ] The "ready" state says "ready, standby answering" or "ready, no standby" so the admin powers off knowingly.
• [ ] Tests cover answering, not answering, and unset.
• [ ] docs/features/maintenance.md documents the variable.

Files: src/maintenance/service.ts, src/web/pages/maintenance.ts, src/http/api.ts, test/, docs/features/maintenance.md. Risk: an outbound fetch from the forge; keep it to the configured URL only.

/maintenance and GET /api/v1/admin/maintenance already say whether the standby page is answering. That work is on this branch from earlier runs. Nothing changed on the issue, and I made no new commits, so there was nothing to push. The branch is clean and in sync with origin, and the 9 tests in test/maintenance-standby.test.ts pass. I did not re-run the gate, tsc or test/maintenance.test.ts this time. They were clean on an earlier run.

• Set URL: when MAINTENANCE_STANDBY_URL is set, the forge fetches only that URL, with a 2 s timeout and no redirects. It reads at most 64 KB. The URL is never taken from a request. Answering means a 503 whose body contains "Back soon".
• Unset: the page says in one line to run bun scripts/standby.ts 8080 on the droplet and point the tunnel or Cloudflare origin at it.
• Ready state: the line reads "Ready, standby answering", "Ready, standby not answering" or "Ready, no standby".
• Tests and docs: the tests cover answering, not answering and unset. docs/features/maintenance.md documents the variable.
• Added beyond the issue: the forge makes at most one live check per URL every 5 s.
• Left out: the forge only checks the standby. It does not start it or push the page to Cloudflare.

To try it, run MAINTENANCE_STANDBY_URL=http://127.0.0.1:8080/ bun run src/main.ts with bun scripts/standby.ts 8080 running, then open /maintenance as an admin.

Parked by the crew: the run ended without a pull: no changes pushed: /maintenance and GET /api/v1/admin/maintenance already say whether the standby page is answering. That work is on this branch from earlier runs. Nothing changed on the issue, and I made no new com

Done on main already, waiting for you to close it: 30f04bdb2b6f3e7f0132c66e0f2f048545ff5dda

Closed: already done on main in 30f04bd. Closed by the crew's live triage; reopen it to undo, and it stays open.