ci: deploy from main via Alchemy (CloudflareStateStore)#121

What changed

• New .github/workflows/deploy.yml: on push to main (and manual dispatch), deploys all four apps in order — server, admin, storev2, agent — each via its own bun run deploy. Serialized with a deploy-production concurrency group (cancel-in-progress: false) so production deploys never overlap. 20-minute timeout, Bun 1.3.0.
• apps/server, apps/admin, apps/storev2 alchemy.run.ts: pass a stateStore to the alchemy(...) call that, only when CI is set, uses CloudflareStateStore so all three apps share Alchemy state in Cloudflare (KV) instead of the local .alchemy filesystem. Locally (CI unset) behavior is unchanged (undefined → default local store).
• apps/server/alchemy.run.ts: added adopt: true to the Hyperdrive("pscale-db", ...) resource so the first CI run adopts the existing Hyperdrive config instead of trying to recreate it.

GitHub secrets to create

• CLOUDFLARE_API_TOKEN — Cloudflare API token with edit on: Workers Scripts, Workers KV Storage, Workers R2 Storage, Durable Objects, Hyperdrive, Workers Routes, DNS; plus Account Settings: Read.
• CLOUDFLARE_ACCOUNT_ID — the target Cloudflare account ID.
• ALCHEMY_STATE_TOKEN — a new, stable secret value used by CloudflareStateStore to authenticate to the shared state backend. Generate once and keep it stable across runs (rotating it orphans state).
• ALCHEMY_PASSWORD — MUST equal the existing local ALCHEMY_PASSWORD used for current deploys. It encrypts/decrypts secret state; a different value cannot read existing state and will break adoption.
• DOTENV_PROD — the full verbatim contents of the local .env.prod file (all prod env vars). The workflow writes this to .env.prod before install/deploy.

Required attended first run BEFORE merging

Do the first deploy locally with CI semantics, watching the log to confirm resources are ADOPTED, not recreated — especially the Hyperdrive (pscale-db) and the Durable-Object-backed workers (server's ProductSearchObject / TransferReconciliationObject). Recreating those would drop the DB binding / DO state.

Run it per app (apps/server, apps/admin, apps/storev2, apps/agent) and verify each resource logs as adopted. Only merge once the attended run is clean.

Note

The --stage prod naming in each app's deploy script is load-bearing — it determines the physical resource names (e.g. server-api-prod, custom domains, WorkerRef({ service: "server-api-${stage}" }) in storev2). Do not change the stage name; it must stay prod for the shared state and cross-app references to resolve.