a missing plugin can no longer stop the platform booting

A server died on `Cannot find module '../../../../plugins/music/db/schema'`
before a line of its own code ran. The pull that broke it was the one untracking
`plugins/` — git deleted those directories from the working tree, and the
gitignored `plugin-schemas.gen.ts` still named them.

The barrel being wrong is NORMAL. It is written by `db:push` and by installing a
plugin, and nothing rewrites it when a directory goes away by other means: a
pull, `git clean -xfd`, `rm`. It describes a machine, not the project, which is
why it is gitignored in the first place.

The defect was not the stale file. It was that a file allowed to be wrong sat in
the import graph of the process that must always start — via `db.ts` →
`schema.ts` → the barrel. An import graph is resolved before `main`, so this
was not catchable, loggable or survivable. Everywhere else the plugin system
already holds the line: `refreshPluginMounts` isolates a bad plugin,
`discoverPlugins` reports a broken manifest instead of throwing. This was the one
remaining path that could take the whole server down, and it took it down.

So the two consumers get their own entry points. `schema.ts` keeps the core
tables and is what the runtime imports. `drizzle-schema.ts` re-exports it, adds
the generated barrel, and is read only by drizzle-kit — which regenerates the
barrel before every run and can afford to fail loudly on a genuinely broken
plugin. `drizzle.config.ts` points at the new one.

Verified by reproducing it: with the barrel naming a plugin directory that does
not exist, importing the server's db module now succeeds while importing
`drizzle-schema.ts` still fails with that exact error — so the runtime is immune
and drizzle-kit's strictness is intact. First attempt at that test was worthless,
since I "poisoned" the barrel with a path that existed here; redone with an
absent one. `bun db:gen` then loaded the new entry and emitted both core and
plugin tables (music_*, offscale_servers), which is what proves `db:push` still
works.

Pulling this is enough to boot a server in that state — the stale barrel stops
being loaded rather than needing to be repaired.

tsgo clean, frontend builds, 865 pass / 7 fail unchanged.

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

scripts/gen-plugin-schemas.ts

@@ -5,9 +5,12 @@ import { generatePluginSchemas } from '../src/servers/plugins/schema';
 //
 // ── The bug this closes ──
 //
-// `officer_db/src/schema.ts` ends with `export * from './plugin-schemas.gen'` — UNCONDITIONAL, because
-// drizzle-kit needs one file listing every table. That generated file is gitignored (it describes this
-// machine, not the project), and until 2026-08-15 its only writer was `installPlugin`.
+// `officer_db/src/drizzle-schema.ts` ends with `export * from './plugin-schemas.gen'` — UNCONDITIONAL,
+// because drizzle-kit needs one file listing every table. That generated file is gitignored (it describes
+// this machine, not the project), and until 2026-08-15 its only writer was `installPlugin`.
+//
+// (It was `schema.ts` until 2026-08-16, which put the barrel in the SERVER's import graph too. A missing
+// plugin directory then stopped the platform booting, so the two entry points were split.)
 //
 // So on a fresh clone the file did not exist, and `bun db:push` died with MODULE_NOT_FOUND before
 // creating a single table. That is exactly what `scripts/setup/officer-setup.sh` section 8 runs, so