feat(db): land the Drizzle schema, config and conventions (#217)

Infrastructure only. No route is converted, nothing changes at run time.

The mirror had already drifted, which settles how it should be maintained. schema.ts was missing item_drafts and upload_links from the moment #222 landed, because the spike pulled into ./drizzle and copied the file into src/ by hand, and nobody had reason to look at the copy for a week. So `out` now points at src/db-drizzle and pull refreshes in place — the copy step that made the drift possible is gone — and tablesFilter excludes pgmigrations, which is node-pg-migrate's bookkeeping and has no business in a model of the application's schema.

A stale mirror is worse than no mirror, because Drizzle infers row types from it: a converted query would type-check against a schema the database does not have and fail at run time on a column that does not exist. drizzleSchema.integration.test.ts fails when the two disagree, on tables and on columns. It was checked by removing item_drafts from the mirror and confirming the test fails naming it, rather than trusting a green run on a file that already matched.

pull also emits 0000_*.sql and meta/ into `out`, because that directory serves both purposes. Both are gitignored: this project's migration history is backend/migrations, hand-written and mostly prose, and #219 has not chosen otherwise — a stray SQL file in src/ is at best noise and at worst mistaken for real history.

db is exported beside pool and shares its connections. Both must work at once, since conversion is file by file across 187 sites; separate pools would make a transaction on one invisible to the other and silently double the configured limits.

The generated files are excluded from linting. #261 hand-fixed an unused-parameter warning in schema.ts and this re-pull put it straight back, which is the argument in one line: linting generated code buys a fix the next regeneration undoes. itemFilters.drizzle.ts, which is hand-written, is still linted.

CONVENTIONS.md records the sql.param() array trap before anyone hits it — the wrong form type-checks, reads correctly and fails at run time as invalid Postgres — and the reason the adoption is worth doing at all, which is that ${value} emits a bind parameter and there is no way to spell "interpolate this as SQL" by accident.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

backend/src/db.ts

@@ -1,4 +1,6 @@
 import { Pool } from 'pg';
+import { drizzle } from 'drizzle-orm/node-postgres';
+import * as schema from './db-drizzle/schema';
 
 export const pool = new Pool({
   host: process.env.PGHOST,
@@ -8,6 +10,27 @@ export const pool = new Pool({
   database: process.env.PGDATABASE
 });
 
+/**
+ * Drizzle over the same pool, alongside `pool` rather than instead of it.
+ *
+ * Both have to work at once: the conversion decided in #216 is file by file
+ * across 187 call sites, so for a long time most queries will still be raw `pg`
+ * and the two must share one set of connections. Handing drizzle the existing
+ * pool rather than letting it open its own is what makes that true — otherwise
+ * a transaction started on one would be invisible to the other, and the pool
+ * limits would silently double.
+ *
+ * The value of this over raw `pg` is not brevity. In a Drizzle `sql` template
+ * `${value}` emits a **bind parameter**, never text, so there is no way to
+ * spell "interpolate this as SQL" by accident — the escape hatch that looks
+ * like a plain template literal does not behave like one. That makes the #202
+ * invariant structural instead of a comment plus two mutation tests, and it is
+ * the main reason this adoption is worth doing.
+ *
+ * The trap that goes with it is arrays. See db-drizzle/CONVENTIONS.md.
+ */
+export const db = drizzle(pool, { schema });
+
 /**
  * The single row a query is guaranteed to have returned.
  *