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.

PLUGIN.md

@@ -56,7 +56,7 @@ liveness, matching every other HTTP sidecar in this codebase.
 
 Decision 3 said to check whether `collections` and `provider_settings` were empty before folding them
 into `officer_db`. Both had rows (2 and 1), so the `atelier` Postgres database stays separate — the
-sidecar keeps its own connection (`sidecar/db/db.ts`), reading `ATELIER_POSTGRES_URL` from the platform
+sidecar keeps its own connection (`sidecar/db/db.ts`), reading `OFFICERDEV_POSTGRES_URL` from the platform
 `.env`. **This is new territory for the plugin system**: `db/schema.ts` at a plugin's root is the
 `officer_db`-prefixed-tables convention (`pushPluginSchema`, `<appname>_` prefix), and this plugin has no
 such file — `discoverPlugins()` correctly reports `schema: null` for it, and the install flow's schema
@@ -65,7 +65,7 @@ step is simply skipped. Nothing in `src/servers/plugins/` needed to change for t
 self-managed database is indistinguishable from a plugin with no tables at all, as far as the platform
 is concerned. Worth knowing before assuming every plugin's data lives in `officer_db`.
 
-**Not set automatically.** `ATELIER_POSTGRES_URL` has no default — see `BLOCKERS.md` for why (mainly:
+**Not set automatically.** `OFFICERDEV_POSTGRES_URL` has no default — see `BLOCKERS.md` for why (mainly:
 pointing it at the live production `atelier` database while that database's own standalone service is
 still running risks two processes racing the same generation queue). The owner has to add it before
 installing.
@@ -168,7 +168,7 @@ expected, not a bug.
 
 1. **Publish to `gitea.officer.dev/plugins/atelier` and register it in the marketplace.** Not done — see
    `BLOCKERS.md` for why and the exact commands.
-2. **`ATELIER_POSTGRES_URL` has to be set before install.** No default, on purpose.
+2. **`OFFICERDEV_POSTGRES_URL` has to be set before install.** No default, on purpose.
 3. **The `atelier` → `officer_db` migration**, described above, once someone can watch it happen.
 4. **`assets/icon.png` and `assets/splash.png` are `[placeholder]`** flat swatches — see
    `assets/PLACEHOLDER.md`.
@@ -176,3 +176,26 @@ expected, not a bug.
    touch the owner's live session or shared database.
 6. **Deciding whether and when to cut the mobile app over** from `atelier.officer.dev` to the plugin's
    route, and what happens to the standalone service afterward.
+
+## Reversed 2026-08-20: officer_db, not a separate database
+
+The extraction kept Atelier's own `atelier` Postgres database, because `BLOCKERS.md` decision 3 said to
+when the tables already had rows. The owner reversed that afterwards, and the reasoning is worth keeping:
+
+**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 that was
+bought by anything except avoiding a migration.
+
+So: four `atelier_`-prefixed tables in `officer_db` — `atelier_collections`, `atelier_collection_items`,
+`atelier_providers`, `atelier_generations` — created empty by `bun db:push`, like every other plugin.
+Index and check constraint names carry the prefix too; those are global in Postgres and would otherwise
+be the one thing that collides.
+
+`ATELIER_POSTGRES_URL` is gone. `sidecar/db/db.ts` reads `OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL`, the
+house convention, which the platform already sets.
+
+**The standalone service's data is NOT here.** It is still in the old `atelier` database, and the old
+service is still running against it, untouched. Migrating those rows — 2 collections, 73 items, 5
+providers, 87 generations — is a deliberate, watched step, done after the plugin is installed and proven
+on alpha. Nothing about this plugin depends on it happening.