v2-platform: 11 sandbox image — same Dockerfile, PGlite/Neon tiering at the DB seam

Parent

#274 (v2 platform services spec)

What to build

The sandbox image: the same static container image as every production host, boot-parameterized only by account and gateway env, running watch mode by default. The database tiering lands here at the existing DB driver seam: PGlite embedded (same Postgres dialect as dev/test/prod — the repo already runs PGlite for tests) selected by config for disposable sandboxes, Neon for production, one image for both. A docker smoke test proves the image boots per-account and serves. Memory posture: the app process is the floor (~300–500MB); PGlite adds bounded tens of MB.

Acceptance criteria

• The production Docker image boots with only account/gateway/DB-engine env differences and serves the account's app
• PGlite engine: a sandbox boots with an embedded database, runs migrations, and serves — zero external DB dependencies
• Neon engine: the same image boots against a provisioned remote database unchanged
• A docker smoke test covers boot-and-serve for both engines
• Watch mode runs by default in the sandbox tier (config change → app updates, no restart)

Blocked by

• #284 (OTA watch runtime)

Start at the existing DB driver seam and the Dockerfile/image configuration, then read parent issue #274 and the blocked OTA watch runtime work in #284. Done means one image boots and serves with either embedded PGlite or remote Neon, runs migrations, supports default watch mode, and passes a Docker smoke test for both engines.