Commit the first migration, and apply schema the same way everywhere

`drizzle/` was gitignored, so every environment re-derived the schema from
src/db/schema and nothing recorded what a given release expected. That is
survivable while nothing is deployed and a problem the moment something is.
The generated migration is now committed: four tables, three enums, five
foreign keys, and the per-farm unique index on gateway_printer_id.

It needed one hand-added line to be usable on its own. drizzle-kit does not
emit extension statements, but frame_embeddings.embedding is vector(512) with
an ivfflat index, so as generated the migration only applied to a database
somebody had already run `CREATE EXTENSION vector` on - which was true locally
precisely because dev-env.sh does that, and would not have been true on a
fresh deploy. `CREATE EXTENSION IF NOT EXISTS vector` now leads the file, and
it survives regeneration: drizzle only appends new migrations, and the diffing
snapshot lives in meta/0000_snapshot.json rather than in the SQL.

Verified by dropping the database, recreating it with no extensions at all
(`pg_extension` count 0), and running db:migrate: the extension and all four
tables were created, `db:generate` then reported no pending changes, and the
e2e script still passed against both live printers on the result.

`dev-env.sh schema` now runs `migrate` instead of `push`, so a local database
and a deployed one get the schema by the same route - testing `push` locally
while production runs `migrate` tests two different things. `push` is still
available as its own command for iterating on a table that is still moving,
with a comment about what it does not record.

README.md

@@ -8,7 +8,7 @@ with pgvector for frame embeddings), Valkey Streams, and Cloudflare R2 storage.
 ```sh
 bun install
 scripts/dev-env.sh up        # Valkey + Postgres/pgvector, and print the URLs
-scripts/dev-env.sh schema    # or: bun run db:migrate
+scripts/dev-env.sh schema    # apply drizzle/ - same as bun run db:migrate
 cp .env.example .env         # fill in the URLs it printed, plus R2_*, SUPABASE_JWT_SECRET
 bun run dev
 ```
@@ -20,6 +20,16 @@ dockerd needs `CAP_NET_ADMIN` for its bridge and user namespaces to unpack an
 image, and neither can be granted from inside. `scripts/dev-env.sh status`
 says which backend is in use.
 
+Schema changes go through migrations: edit `src/db/schema/`, run
+`bun run db:generate`, and commit the file it writes to `drizzle/` along with
+the schema change. `scripts/dev-env.sh push` reshapes a local database straight
+from the schema with no migration file, which is faster while a table is still
+moving but records nothing and will drop a column to make things match - so
+generate before committing. `drizzle/0000_*.sql` creates the `vector` extension
+itself; that line is hand-added, since drizzle-kit does not emit extension
+statements and the migration would otherwise only apply to a database somebody
+had already prepared.
+
 ## Test
 
 ```sh
@@ -61,8 +71,9 @@ Valkey and Postgres+pgvector for local development.
   (`"p1p"`) onto rows here; telemetry for an unclaimed id is logged and skipped,
   never inserted.
 
-`frame_embeddings.embedding` requires the `vector` extension:
-`CREATE EXTENSION IF NOT EXISTS vector;` (`scripts/dev-env.sh up` does this).
+`frame_embeddings.embedding` requires the `vector` extension. The first
+migration creates it, and `scripts/dev-env.sh up` also does so for the `push`
+path, which does not run migrations.
 
 ## Dependency pins