officer_db with atelier_ prefixes, like every other plugin

the extraction kept atelier's own postgres database, because the brief said to
when the tables already had rows. the owner reversed it, and the reason is not
tidiness: a plugin that behaves differently from every other plugin is a
plugin nobody can reason about.

the separate database meant a second connection string to set before install,
a second thing to back up, a second thing to get wrong on a new machine, and
failure modes no other plugin shares — none of it bought anything except
avoiding a migration.

four tables now: atelier_collections, atelier_collection_items,
atelier_providers, atelier_generations. index and check constraint names carry
the prefix too — those are global in postgres and are the one thing that would
otherwise collide with another plugin.

db/schema.ts re-exports the definitions rather than duplicating them: they stay
beside the code that queries them in sidecar/db/, and that file exists to be
found by gen-plugin-schemas.

ATELIER_POSTGRES_URL is gone. db.ts reads OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL,
which the platform already sets.

the standalone service's rows are NOT here and nothing depends on them being
here — the old service is still running against the old database, untouched,
and migrating is a separate watched step after this is proven on alpha.

sidecar/db/db.ts

@@ -2,22 +2,22 @@ import { drizzle } from 'drizzle-orm/postgres-js';
 import postgres from 'postgres';
 import * as schema from './schema';
 
-// The `atelier` Postgres database — separate from officer_db, on purpose. See PLUGIN.md.
+// officer_db, like every other plugin.
 //
-// `ATELIER_POSTGRES_URL` rather than officer's own `OFFICERDEV_POSTGRES_URL`/`POSTGRES_URL`: this
-// plugin talks to a different database on (most likely) the same Postgres server, and the platform's
-// own connection string must never be reused here by accident — the standalone service's
-// `atelier_db/src/env.ts` had a whole enforcement mechanism for exactly this mistake ("a development
-// process cannot reach the production database"), which no longer applies once this runs as one
-// process under one PM2 entry, but the principle — don't let this plugin's queries land on the
-// platform's own tables — still does.
-const POSTGRES_URL = process.env.ATELIER_POSTGRES_URL;
+// This originally connected to a separate `atelier` database via `ATELIER_POSTGRES_URL`, carried over
+// from the standalone service. Reversed on 2026-08-20 by the owner: the tables are `atelier_`-prefixed
+// in officer_db, the plugin starts empty, and the standalone service's rows are migrated afterwards
+// with someone watching.
+//
+// The reason is not tidiness. A second database meant a second connection string to set, a second thing
+// to back up, and a plugin whose failure modes nobody else's plugin shares. `OFFICERDEV_POSTGRES_URL ?? 
+// POSTGRES_URL` is the house convention (src/servers/env-prefix.ts), and the standalone repo's whole
+// "a development process cannot reach production" enforcement stops applying once this is one process
+// under one PM2 entry.
+const POSTGRES_URL = process.env.OFFICERDEV_POSTGRES_URL ?? process.env.POSTGRES_URL;
 
 if (!POSTGRES_URL) {
-  throw new Error(
-    'ATELIER_POSTGRES_URL environment variable is required — set it in the platform .env to the ' +
-      '`atelier` Postgres database this plugin should use. See plugins/atelier/PLUGIN.md.',
-  );
+  throw new Error('OFFICERDEV_POSTGRES_URL (or POSTGRES_URL) is required — the platform sets it in .env.');
 }
 
 /**