ci: read the production env from Infisical and deploy on push

Each job logs in as the read-only spoon-ci machine identity and exports the Infisical prod environment, so production values no longer live in Gitea. After pushing the images, CI asks the VPS to redeploy podman-spoon.service over the forced-command deploy key, with the key passed through env so the printed script never contains it. Installs survive a half-written runner cache, and one production deploy runs at a time.

Infisical prod carries a valid JWKS; the copy in DOTENV_PROD had escaped quotes, so the Convex env sync had been serving invalid JSON at /.well-known/jwks.json. The first sync from Infisical replaces it.

AGENTS.md

@@ -70,7 +70,13 @@
 - Old terminal workspaces can be deleted from `Settings -> Worker`; orphaned
   containers/workdirs are cleaned through the worker HTTP API, not from the
   browser directly.
-- CI uses Gitea-injected secrets or `CI_ENV_FILE` and must not call Infisical.
+- CI reads Infisical `prod` through `scripts/ci-export-env.mjs`, logged in as the
+  read-only `spoon-ci` machine identity (Gitea secrets `INFISICAL_CLIENT_ID` and
+  `INFISICAL_CLIENT_SECRET`), and hands the result to the scripts as
+  `CI_ENV_FILE`. `scripts/export-env` refuses to run in CI.
+- A push to `main` builds the images, syncs the Convex env, deploys Convex, pushes
+  the images, and asks the VPS to redeploy `podman-spoon.service`
+  (`ssh [email protected] spoon`). A push to `main` is a production deploy.
 - Gitea image builds force `SPOON_AGENT_CONTAINER_RUNTIME=docker`; keep local
   Podman auto-detection out of CI image tagging/pushing.
 - CI must provide Convex deployment env for codegen, either