fix(H-11): /health carries the deployed commit, and both verifiers check it

[vjvarada]

Why

CommandCenter is not down — it was replaced in place. A forked product
(Metorite) was deployed onto the CommandCenter VPS and has been serving
commandcenter.fracktal.in since 2026-08-25, under the title Metorite Control
Plane. The owner's symptom was "none of the apps are there, I can't reach my
email".

Nothing is wrong with the apps, and nothing in this repo needs reverting —
app visibility resolves from grants × feature_catalog (unioned with a code
mirror) in /admin/me, with no subscription, entitlement or tenancy gate
anywhere on that path. The multi-tenancy work did not hide anything.

What failed is that every verifier we own asked a liveness question, and a
different product answers those perfectly:

verifier	what it asked	verdict during the takeover
vps-health.yml	"any HTTP response means the stack is serving" (its own comment)	🟢 green, hourly, for two days
deploy.yml verify()	/health 200 and workbench 2xx/3xx	🟢 would bless a deploy that shipped nothing

Liveness is not identity. This PR adds the second question.

What changed

• /health carries sha — the commit the process is serving, from
  ACB_GIT_SHA or the checkout. Cached, and never fatal: the on-box watchdog
  restarts services off this endpoint, so an identity lookup that could raise
  would turn "I can't tell you which commit" into "the box is dead".
  A SHA rather than a product name, deliberately — a rebranded fork
  inherits every string constant we could put there, but cannot inherit our
  commit ids.
• deploy.yml asks "did MY commit ship?" (served sha == GITHUB_SHA).
  A foreign stack, a gateway that never restarted, and a mid-apply SSH timeout
  all fail that question; all three passed the old one.
• vps-health.yml asks "is that OUR history at all?" — git cat-file -e
  against a full checkout, plus the workbench <title> as a second signal that
  still works on boxes predating the endpoint. Either reading foreign is an
  outage.
• Alert wording generalised. "VPS unreachable" misdescribes a takeover —
  which is emphatically not an outage you restart your way out of, since
  restarting would only restart the other product.

Verification

Run against the live host, not a fixture:

IDENTITY=unverified BRAND=foreign HEALTHY=0
- brand FOREIGN "Metorite Control Plane"
- identity UNVERIFIED and brand not ours

The old logic returned healthy for that same host. And the converse — a check
that always alarms would be no better:

case	result
genuine box on new code (sha resolves)	✅ healthy
genuine box predating the endpoint (no sha, correct title)	✅ healthy + nudge to redeploy
the actual takeover (foreign sha / foreign title)	🔴 unhealthy

5 passed on the new suite, 25 passed including the gateway auth suites,
both workflow YAMLs parse, and ruff findings on main.py are unchanged at 18
(no new lint debt).

H-11 repaired

Its Check named /version — which CommandCenter does not have.
tasks_lens, a field in the response the box returns, appears nowhere in this
repository: /version is a Metorite route. The Check would have read "still
pending" forever after a perfect recovery, when the route simply 404s. Now
keyed on the workbench title and /health's sha.

Also re-measured today and recorded:

1. ✅ The bleed has stopped — Metorite deploys to its own box now
   (187.127.172.200, serving today's HEAD); .143 has been frozen since
   2026-08-26T08:05Z.
2. 🔴 A new risk: CommandCenter's HOSTINGER_HOST was changed
   2026-08-25T14:22Z and secret values are unreadable — so which box we
   deploy to is unknown. If it was repointed at .200, re-running our deploy
   clobbers Metorite's live box: the same accident in the other direction.
   Reading both repos' values is now step 1 of the runbook.
3. ⚠️ R1 collision grew 188 → 192 while we sit at 176.
4. ⚠️ Metorite's 190_gtd_retirement_drop.sql does DROP TABLE gtd_items
   / gtd_waiting (the tasks tables) and merged inside the window when
   .143 was deploying Metorite — but it is triple-guarded and inert unless
   deliberately armed. Data loss expected zero; the confirming queries are in
   the runbook, because that is read from the migration text and not yet from
   the box.

Not in this PR — owner-gated (work_plan.md §6)

Taking the box back: VPS reach, deploy, cutover. The runbook is H-11.
This PR is the part that makes the recovery verifiable by evidence rather
than by a green job (CLAUDE.md §3.8) — which the old /version-based Check
could not do.

🤖 Generated with Claude Code