Read CI env from Infisical and give the local stack its own ports

CI reads Infisical staging as the read-only convexmonorepo-base-ci machine identity, runs the quality gate, and builds and pushes the image. The template is not deployed, so there is no Convex or VPS deploy step. The local stack moves to its own Compose name and ports so it runs beside the Payload template's, and it syncs the Convex runtime env. The scripts pick up Infisical account switching, dev-kill and a cache-safe CI install.

README.md

@@ -5,7 +5,8 @@ shared UI/config packages, Vitest, and Docker deployment.
 
 ## Local setup
 
-Requirements: Bun 1.3.10, Docker or Podman, Node 22, and the Infisical CLI.
+Requirements: Bun 1.3.14, Docker or Podman, Node 22, the Infisical CLI, `jq`, and
+`flock`.
 
 ```sh
 bun install --frozen-lockfile
@@ -22,8 +23,8 @@ files. Select staging with `INFISICAL_ENV=staging bun dev:next`.
 Local services:
 
 - Next.js: `http://localhost:3000`
-- Convex API: `http://localhost:3210`
-- Convex dashboard: `http://localhost:6791`
+- Convex API: `http://localhost:3250`
+- Convex dashboard: `http://localhost:6795`
 
 Next and Expo run on the host. Convex uses a self-hosted data volume and does
 not use Postgres by default. The commented `POSTGRES_URL` in Compose is an
@@ -46,7 +47,8 @@ Convex URL with the development host's LAN address when testing Expo on-device.
 
 - Local `dev` and `staging`: Infisical.
 - Generated local state: `.local/<environment>.generated.env`.
-- CI/CD: Gitea `DOTENV_PROD`, materialized only as a temporary runner file.
+- CI/CD: Infisical `staging`, read by the read-only `convexmonorepo-base-ci`
+  machine identity and materialized only as a temporary runner file.
 - Docker compilation: explicit Compose build args; `.env*` stays outside the
   image context.
 
@@ -81,5 +83,11 @@ Shared dependency versions belong in root catalogs. Edit the root catalog, run
 Production Compose retains the self-hosted Convex backend/dashboard and has no
 Postgres service by default. A commented `POSTGRES_URL` remains only as an
 optional Convex-on-Postgres example for cloned projects. Gitea runs the quality
-gate first, builds the Next image from a temporary Gitea-secret env file, then
-pushes SHA and `latest` tags. CI never installs or invokes Infisical.
+gate first, then builds the Next image and pushes SHA and `latest` tags. Each
+job reads Infisical `staging` through `scripts/ci-export-env.mjs` as the
+`convexmonorepo-base-ci` machine identity (Gitea secrets `INFISICAL_CLIENT_ID`
+and `INFISICAL_CLIENT_SECRET`).
+
+The template itself is not deployed. A cloned app that is adds a `convex-deploy`
+job and the VPS deploy step from an app that already has them (StPeteIT,
+LashAddict, bill-tracker), plus its own Infisical project and machine identity.