Isolate the storage CI stack, prove least-privilege provisioning, drop the secret before discovery

AGENTS.md

@@ -97,9 +97,14 @@ Revisit only if the stated reason stops holding.
   *accidents*, not hostile plugins: `PLUGIN_DB_SECRET` is in `web`'s environment during `onBoot`, and
   a plugin already holds `ctx.system`'s Ory admin clients — so cross-plugin DB isolation is
   containment, and README says so rather than implying a sandbox. Consistent with priority #7
-  (crash-isolation is a non-goal). `server.ts` still derives every credential *before* the boot hooks
-  and then deletes the secret from `process.env` — defence in depth, and the ordering is the whole
-  point, so don't move it. **Valid while plugins are operator-installed code, not third-party uploads.**
+  (crash-isolation is a non-goal). `server.ts` still deletes the secret from `process.env` right
+  after `loadConfig`, which is before discovery imports any plugin module — the ordering is the whole
+  point, so move it earlier if anything, **never later**. **Valid while plugins are
+  operator-installed code, not third-party uploads.**
+- **`bootstrap.ts` stays under `src/auth/`** even though it now provisions plugin databases as well
+  as seeding Ory. It is the one-shot service's entrypoint, not an auth module; moving it to
+  `src/bootstrap.ts` would edit `compose.yml`, five e2e compose files and `src/compose.test.ts` for a
+  rename. Reconsider when a third seeding concern lands.
 - **`BootContext.storage` keeps all six credential fields, and there is no `onShutdown` hook.** While
   `HOST_API_VERSION` is frozen both are free to revisit; after the freeze, adding is compatible and
   removing is not, so the shape errs small elsewhere. Pools handed to a plugin are reaped on process