feat(deploy): add stage tier — park-buzi as the staging booth

Model the staging-vs-production split that fleet-deployment-komodo flagged as open.
Three tiers: dev (working, no booth) -> stage (staging booth park-buzi, real-world
test) -> main (production, manual + pinned).

- build-images.yml: trigger on [dev, stage, main]. The tag computation is already
  branch-derived, so :stage / :stage-<sha> build with no other change.
- komodo/resources.toml: park-buzi now branch=stage + TAG=stage-<sha> (pinned;
  no webhook even on staging). BACKUP_KEY already wired as a per-booth secret.
- komodo/README.md: a Promotion (dev->stage->main) section; per-booth secret list
  now includes backup_key; hard-rule #1 generalised to pinned <branch>-<sha>.
- wiki: fleet-deployment-komodo open-item resolved + a Promotion-tiers table;
  deploy-trigger choice generalised; container-deployment tag list gains :stage.

Promotion is a merge: when dev is ready, merge dev->stage, CI builds the image,
bump TAG=stage-<sha> in resources.toml, deploy from Core. stage is branched from
dev HEAD so the first real-world test carries the full current app. Per-booth
secrets must pre-exist in Core; migrations run at boot so a promotion auto-migrates
the staging ledger (where a bad migration is caught before production).

Claude-Session: https://claude.ai/code/session_01Xcm6ikLgGoCxxHrxtjkk5V

komodo/README.md

@@ -16,7 +16,22 @@ run `booth.sh`.
   Procedures), synced into Core via a **ResourceSync**. This is the reviewable, version-
   controlled source of truth for *which booth runs what*.
 - **`.env.komodo.example`** — the variables a Stack expects, documenting what comes from Core's
-  **secret store** (per-booth `JWT_SECRET` / `EVENT_SIGNING_KEY`) vs. plain Stack env.
+  **secret store** (per-booth `JWT_SECRET` / `EVENT_SIGNING_KEY` / `BACKUP_KEY`) vs. plain Stack env.
+
+## Promotion: dev → stage → main
+
+Three tiers (see `wiki/decisions/fleet-deployment-komodo.md`):
+
+- **`dev`** — the working branch. CI builds `:dev` / `:dev-<sha>`. No booth deploys off it.
+- **`stage`** — what the **staging booth (`park-buzi`)** runs, to test the app in real-world
+  conditions. When `dev` is confident-ready, **merge `dev → stage`**; CI builds `:stage` /
+  `:stage-<sha>`; then **bump `TAG=stage-<sha>` in `resources.toml`** to that build and deploy
+  from Core (manual, pinned — no webhook even on staging).
+- **`main`** — vetted **production** booths: `:main-<sha>`, manual + pinned. `main` only gets what
+  survived staging.
+
+> The `TAG=stage-<sha>` in `resources.toml` is a **pinned pointer**: the moving `:stage` tag exists
+> but we deploy the immutable sha so a booth runs a known image. Re-pin on each promotion.
 
 ## How Core consumes this (one-time)
 
@@ -43,14 +58,16 @@ booth), and connects **outbound** — the booth opens **no inbound port**. The s
 ## Adding booth N
 
 Copy the `[[stack]]` block, change `name`, `server` (its onboarded name), and the per-booth
-secret references (`[[park_<site>_jwt_secret]]`, `[[park_<site>_event_signing_key]]`). Create
-those secrets in Core's store first.
+secret references (`[[park_<site>_jwt_secret]]`, `[[park_<site>_event_signing_key]]`,
+`[[park_<site>_backup_key]]`). Create those secrets in Core's store first. Set `branch` +
+`TAG` for the tier the booth runs (staging → `stage` / `stage-<sha>`; production → `main` /
+`main-<sha>`).
 
 ## Hard rules encoded here (do not relax without updating the decision page)
 
-1. **No deploy webhook on a booth Stack.** Deploys are a human action; pin `TAG=dev-<sha>` before
-   a production booth goes live. A moving `:dev` on a production booth is the non-determinism we
-   rejected. (`TAG=dev` here is fine while staging.)
+1. **No deploy webhook on a booth Stack.** Deploys are a human action; pin an immutable
+   `TAG=<branch>-<sha>` (staging → `stage-<sha>`, production → `main-<sha>`). A moving tag on a
+   booth is the non-determinism we rejected — and we hold that line even on the staging booth.
 2. **Onboarding, outbound, mesh-only.** Servers self-register via an onboarding key; Periphery
    connects outbound to Core's mesh URL and exposes no inbound port. Never a LAN/WAN address.
 3. **Secrets are per-booth and unique.** `EVENT_SIGNING_KEY` signs the anti-fraud ledger — one