Redeploy Environment Route

Admin-only: re-drive a BYOC environment deploy.

environment_deploy now runs as a DBOS durable workflow (run_environment_deploy, environment_deploy.v1). A backend rollout or worker crash mid-deploy no longer fails the deploy — DBOS resumes it from the last completed step on the next worker — and the legacy reaper no longer governs deploy operations (it skips runtime='dbos' rows). So this route is a manual re-drive for the residual cases the automatic path does not cover: a genuinely terminal failure, or a deploy whose workflow died after reaching a terminal error (e.g. the success write exhausted its retries, leaving the environment stuck provisioning with a terminal operation that nothing else re-drives). Because every deploy step is idempotent, customer-triggered retries are now safe too.

Everything the workflow needs is already persisted: the environments row, its environment_resources rows, and the AKV-referenced external_id / neon_api_key. It re-reads all of it from environment_id alone, so an operator can re-drive a stuck deploy with no customer involvement.

Behavior by current status:

• failed — claim a fresh deploy (flip to provisioning, enqueue).
• pending / provisioning — if a deploy workflow is genuinely live, return its operation unchanged; otherwise the prior operation stranded, so terminalize it and enqueue a fresh one (the environment is already provisioning).
• anything else — 409.

Returns 202 with an operation_id; an EKS environment deploy routinely runs ~25 minutes and would otherwise blow the ALB 60s idle timeout. The caller polls GET /v1/operations/{id} for stage transitions and the terminal outcome.