switch off Vaultwarden's routers, pending extraction into a plugin

Same treatment as the browser relay: mounts commented, code left on disk. Its
tables were already commented out of the schema earlier tonight, which is what
made this necessary — /api/vault was mounted against tables db:push no longer
creates, so a fresh core install shipped an endpoint that could only fail with a
Postgres "relation does not exist".

Vaultwarden is not one mount. Eight places had to go, and grepping for `vault`
found them only because several are not named after a router:

  hono.ts   /api/vault                      the authenticated reverse-proxy
            /vaultwarden                    the unauthenticated one for the browser extension
            VAULT_ONLY_PREFIXES loop        /identity, /notifications, /icons, /events
            the isBitwardenClient diverter  an /api/* middleware that hands Bitwarden
                                            clients to the vault router before anything else sees them
            ./api/vault/sidecar-server      a SIDE-EFFECT import capturing the sidecar's port
            UNPROTECTED_API_PREFIXES        the '/vault' entry
  server.tsx  the 'vault' ws provider, its handler, and the notifications upgrade route

The side-effect import is the one worth naming: it registers a sidecar listener
and appears in no route table, so nothing about unmounting the routers would have
stopped it running.

No capability registry change, unlike browser and task-logs. Vaultwarden is
exempt from totality on both halves — EXEMPT_API_PREFIXES has '/vault'
("Bitwarden protocol clients authenticate to Vaultwarden, not to Officer") and
EXEMPT_WS_PROVIDERS has 'vault'. So nothing claims it and nothing breaks by
unmounting it. I said the opposite before checking; the check is what settled it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/servers/hono.ts

@@ -20,8 +20,8 @@ import { settingsRouter } from './api/settings/settings';
 import { dashboardsRouter } from './api/dashboards';
 import { router as fileBrowserRouter } from './api/file-browser/router';
 import { musicRouter } from './api/music/router';
-import { vaultRouter } from './api/vault/router';
-import { publicVaultRouter, VAULT_ONLY_PREFIXES, isBitwardenClient } from './api/vault/public-router';
+// import { vaultRouter } from './api/vault/router';
+// import { publicVaultRouter, VAULT_ONLY_PREFIXES, isBitwardenClient } from './api/vault/public-router';
 import { agentHandoffRouter } from './api/agent-handoff/router';
 import { slskdRouter } from './api/slskd/router';
 import { headscaleRouter } from './api/headscale/router';
@@ -44,7 +44,7 @@ import { systemMonitorRouter } from './api/system-monitor/system-monitor';
 import { activityRouter } from './api/activity/router';
 // Vault still hand-rolls its port capture, so it keeps a side-effect import; every other HTTP sidecar
 // registers its listener when createSidecarProxy runs inside the router this file already imports.
-import './api/vault/sidecar-server'; // side-effect: capture the officer-vault reverse-proxy port
+// import './api/vault/sidecar-server'; // side-effect: capture the officer-vault reverse-proxy port
 import { dockRouter } from './api/dock/dock';
 import { integrationsRouter, googleCallbackHandler } from './api/integrations/integrations';
 import { queueRouter } from './api/queue/queue';
@@ -101,7 +101,7 @@ honoServer.route('/api/waitlist', waitlistRouter);
 // Vaultwarden reverse-proxy — mounted TOP-LEVEL (not under protectedRouter): the Bitwarden client
 // carries its own bearer token, not a platform session JWT, so userMiddleware would 401 it. The
 // notifications WebSocket is upgraded at the serve level (server.tsx).
-honoServer.route('/api/vault', vaultRouter);
+// honoServer.route('/api/vault', vaultRouter);  // switched off 2026-08-13 — Vaultwarden is a plugin
 
 // The same Vaultwarden, with NO Officer authentication, so the Bitwarden browser extension can point at
 // this host instead of at a second public hostname for Vaultwarden. Deliberately its own mount rather
@@ -109,7 +109,7 @@ honoServer.route('/api/vault', vaultRouter);
 // Authorization header for a server-held token, and blending the two would put an unauthenticated branch
 // inside the authenticated path. Temporary — see public-router.ts for what replaces it and why leaving it
 // open is not a new exposure.
-honoServer.route('/vaultwarden', publicVaultRouter);
+// honoServer.route('/vaultwarden', publicVaultRouter);  // switched off with the above
 
 // …and at the ROOT, so the extension can be pointed at the bare Officer URL with no path at all.
 //
@@ -117,12 +117,12 @@ honoServer.route('/vaultwarden', publicVaultRouter);
 // for a Bitwarden client. It is deliberately narrow: the four prefixes below belong to Vaultwarden and
 // to nothing else here, and `/api/*` is diverted ONLY when the request carries a Bitwarden client
 // header. An ordinary Officer request never matches, so nothing that worked before changes.
-for (const prefix of VAULT_ONLY_PREFIXES) honoServer.route(prefix, publicVaultRouter);
-
-honoServer.use('/api/*', async (ctx, next) => {
-  if (!isBitwardenClient(ctx.req.raw.headers)) return next();
-  return publicVaultRouter.fetch(ctx.req.raw, ctx.env);
-});
+// for (const prefix of VAULT_ONLY_PREFIXES) honoServer.route(prefix, publicVaultRouter);
+//
+// honoServer.use('/api/*', async (ctx, next) => {
+//   if (!isBitwardenClient(ctx.req.raw.headers)) return next();
+//   return publicVaultRouter.fetch(ctx.req.raw, ctx.env);
+// });
 honoServer.get('/api/integrations/google/callback', googleCallbackHandler);
 
 // Agent-to-agent handoff — mounted TOP-LEVEL for the same reason the vault is: the caller is a Claude
@@ -243,7 +243,7 @@ export const UNPROTECTED_API_PREFIXES: string[] = [
   '/auth',
   '/landing-page-data',
   '/waitlist',
-  '/vault',
+  // '/vault',  // switched off with the Vaultwarden mounts — see above
   '/sidecar',
   '/agent-handoff',
 ];