re-enable vault — plugin extraction deferred, this is the same code as before

Reverses 1eecc400 ("switch off Vaultwarden's routers, pending extraction into
a plugin"). That plan is on hold: vault, unlike offscale/email/music, is a
Docker-provisioned service through the old app-store catalogue
(sidecar_installs, composeTemplate: 'vaultwarden') rather than a self-
contained sidecar, and the new plugins/ system has no equivalent yet for
provisioning a container. Design work for that is separate, future, explicitly
deferred by the owner rather than attempted here.

What's actually needed right now is narrower: the owner's own Vaultwarden
instance is already running, untouched, externally. This restores exactly the
code that was there before 2026-08-13 — both routers (owner-authenticated
/api/vault for Officer's own clients, unauthenticated /vaultwarden + root
Bitwarden paths for third-party clients), the websocket notifications hub, the
sidecar's port-capture side-effect import, and the vault schema export. All of
it was left commented rather than deleted specifically so this restoration
would be a straight uncomment, per the original commit's own reasoning.

Verified before touching anything: no data was at risk. vault_tokens/
vault_unlock_keys did not exist in Postgres (dropped by a db:push after the
schema was commented out, before this session), and there is no
sidecar_installs row for vault on this machine — nothing to lose, nothing to
migrate.

Confirmed the auth split resolves cleanly without any core changes:
vaultRouter (/api/vault) does its OWN userMiddleware + owner-only gate
internally, so it needs no special exemption — the totality.ts entries for
'/vault' and 'vault' were already present, unaffected by the mount being
commented out, and needed no changes here. Only the unauthenticated
publicVaultRouter genuinely depends on the EXEMPT_API_PREFIXES/
UNPROTECTED_API_PREFIXES carve-out, which is explicitly documented in-code as
TEMPORARY: it goes away once a first-party browser extension authenticates to
Officer directly instead of to Vaultwarden.

bunx tsgo clean, suite at its 7 pre-existing baseline failures, no new ones —
the code had not drifted while dark.

Still needed, not done here (deliberately left to the owner, same as every
restart this session): set VAULTWARDEN_URL in .env to the real server address,
add an officer-vault PM2 entry (ecosystem.config.cjs has none — this was never
in CORE_PROCESSES and there is no plugin/sidecar_installs row driving it),
bun db:push to recreate vault_tokens/vault_unlock_keys, restart officer.

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

src/databases/officer_db/src/schema.ts

@@ -52,7 +52,7 @@ export * from './service-connections/schema'; // service_connections
 // export * from './jellyfin/schema';      // jellyfin_servers                                 officer-jellyfin
 // export * from './invoiceshelf/schema';  // invoiceshelf_accounts                            officer-invoiceshelf
 // export * from './soulseek/schema';      // soulseek_favorites, _browse_snapshots, _browse_dirs
-// export * from './vault/schema';         // vault_tokens, vault_unlock_keys                  officer-vault
+export * from './vault/schema'; // vault_tokens, vault_unlock_keys                  officer-vault
 // export * from './wallet/schema';        // wallet_wallets, _labels, _frozen_utxos, _chain_cache
 
 // ── Plugin tables are NOT here ───────────────────────────────────────────────────────────────────