Reviewed changes — full review of the preview stop/start + idle-to-zero feature: enum consolidation, the relocated every-minute idle cron, branch-displacement spin-down, and the manual stop/wake stack across Restate, connect RPC, tRPC, and dashboard.

• Consolidate desired_state to running/stopped — drops standby and archived from the MySQL enum, the Drizzle schema, and the proto state machine (ChangeDesiredState), and points all callers at the single STOPPED value.
• Relocate idle scaledown to a cron handler — moves the scan from the deploy worker into idlepreview/handler.go, lowers the idle window to 1h, and schedules it every minute as a singleton-keyed CronService object.
• Spin down previous branch deployments — when a preview becomes ready, spinDownPreviousDeployments schedules sibling running deployments on the same branch to stop after a 1-minute grace via the new ListRunningDeploymentsByBranch query.
• Manual stop/wake — adds StopDeployment/WakeDeployment Restate handlers, public connect RPCs, tRPC routers with audit logging, UI dialogs, and canStop/canWake eligibility; wake polls instance health inline until ready or regionReadyTimeout.
• Add Overwrite to ScheduleDesiredStateChange — lets explicit user intent (swapLiveDeployment, manual stop) replace a pending transition while the idle cron and branch spin-down yield with Overwrite:false.

⚠️ Enum drop has no data-backfill migration and standby was in active use

The desired_state enum is narrowed from three values to two, but there is no migration in the PR to rewrite existing rows. The description states neither old value "was ever used", which does not hold for standby: the previous swapLiveDeployment, promote_handler, and the old idle cron all scheduled demoted deployments to STANDBY, so any production database that has ever promoted or rolled back a deployment has live standby rows.

Dropping an enum member while such rows exist is unsafe: in MySQL strict mode the ALTER fails outright, and in non-strict mode out-of-range values are silently coerced to the empty string '', which then fails every Go enum scan on read.

# Enum drop has no data-backfill migration

## Affected sites
- `pkg/mysql/schema/deployments.sql:21` — enum narrowed to `('running','stopped')`. This is the declarative dev schema (applied fresh via `dev/Dockerfile.mysql` initdb), so dev is fine; production is not covered by any in-repo migration mechanism.
- `web/internal/db/src/schema/deployments.ts:60` — Drizzle schema updated to match, no accompanying migration file.
- `svc/ctrl/worker/deploy/deploy_handler.go` (was `STANDBY` in `swapLiveDeployment`), `svc/ctrl/worker/deploy/promote_handler.go:160` (was `STANDBY`) — prior code that wrote `standby` to demoted deployments, confirming the value is populated in prod.

## Required outcome
- A forward migration runs `UPDATE deployments SET desired_state = 'stopped' WHERE desired_state IN ('standby','archived')` BEFORE the `ALTER TABLE ... MODIFY COLUMN desired_state ENUM('running','stopped') ...`, and the code that reads/writes `stopped` is sequenced after the `ALTER` lands.

## Open questions for the human
- How are production MySQL schema changes applied for this repo (the schema dir is declarative for dev only)? Whoever owns that path needs the backfill + ALTER ordering above.
- Confirm whether `archived` was genuinely never written; even if so, `standby` clearly was.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

Happy path works but I have some questions.

When we make a new production deployment, the old deployment can become stopped at swapLiveDeployment. But in wake.go and wake.ts we don't guard against production, and in getDeploymentActionEligibility we don't guard against production either. So technically we can wake a production deployment, and that might disrupt the system?