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.

db/schema.ts

@@ -0,0 +1,15 @@
+// The plugin's tables, where the platform looks for them.
+//
+// `scripts/gen-plugin-schemas.ts` writes `plugin-schemas.gen.ts` from every plugin's `db/schema.ts`, and
+// that generated barrel is what `bun db:push` reads. So this file exists to be FOUND — the definitions
+// themselves live beside the code that queries them, in `sidecar/db/`, and are re-exported here rather
+// than duplicated.
+//
+// Everything is `atelier_`-prefixed and lives in officer_db, exactly like every other plugin. The
+// extraction originally kept Atelier's own `atelier` database, on the reasoning that its tables already
+// had rows. That was reversed on 2026-08-20: the plugin starts EMPTY here, and the standalone service's
+// data is migrated deliberately afterwards, with someone watching. A plugin that behaves differently
+// from every other plugin is a plugin nobody can reason about.
+export * from '../sidecar/db/collections/schema';
+export * from '../sidecar/db/generations/schema';
+export * from '../sidecar/db/providers/schema';