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/server.tsx

@@ -18,7 +18,7 @@ import { chatWebsocket } from './servers/api/chat/websocket';
 import { taskRunnerWebsocket } from './servers/api/tasks/task-executor';
 import { pipelineWebsocket } from './servers/api/tasks/pipeline-executor';
 // import { desktopWebsocket } from './servers/api/desktop/websocket';
-// import { vaultWebsocket, upgradeVaultWs } from './servers/api/vault/websocket';
+import { vaultWebsocket, upgradeVaultWs } from './servers/api/vault/websocket';
 import officerWeb from './apps/officer-web/index.gen.html';
 // import { startBrowserRelay } from './servers/api/browser/relay';  // switched off — see below
 import { registerSidecar, unregisterSidecar, handleSidecarMessage } from './servers/sidecar-registry';
@@ -144,7 +144,7 @@ const handlers: Record<string, any> = {
   'task-runner': taskRunnerWebsocket,
   pipeline: pipelineWebsocket,
   // desktop: desktopWebsocket,
-  // vault: vaultWebsocket,
+  vault: vaultWebsocket,
   sidecar: sidecarWebsocket,
 };
 
@@ -407,10 +407,10 @@ const server = serve({
     },
     // Vaultwarden notifications hub: upgrade the WebSocket here (proxied to upstream by vaultWebsocket);
     // everything else on this path (SignalR long-poll negotiate/poll) falls through to the HTTP proxy.
-    // '/api/vault/notifications/*': (req, server) => {
-    //   if (req.headers.get('upgrade') === 'websocket') return upgradeVaultWs(req, server);
-    //   return honoServer.fetch(req, server);
-    // },
+    '/api/vault/notifications/*': (req, server) => {
+      if (req.headers.get('upgrade') === 'websocket') return upgradeVaultWs(req, server);
+      return honoServer.fetch(req, server);
+    },
     // A dev server's HMR socket, framed by the Preview panel. Must be in the route table rather than
     // behind the `/api/*` catch-all: Bun matches this table first, and an upgrade that reaches Hono is
     // an ordinary GET by then.
@@ -441,14 +441,14 @@ const server = serve({
     // entry for the same reason /dav does: only the paths listed here reach hono, and anything else
     // falls through to the SPA — which answers 200 with the React shell, so a missing line here looks
     // like a working endpoint returning nonsense rather than a 404.
-    // '/vaultwarden/*': honoServer.fetch,
+    '/vaultwarden/*': honoServer.fetch,
     // The same proxy at the root, so the extension needs only the bare Officer URL. These four prefixes
     // are Vaultwarden's alone — nothing in Officer answers on them — so routing them here costs nothing.
     // `/api/*` already reaches hono below, where a Bitwarden client header diverts it.
-    // '/identity/*': honoServer.fetch,
-    // '/notifications/*': honoServer.fetch,
-    // '/icons/*': honoServer.fetch,
-    // '/events/*': honoServer.fetch,
+    '/identity/*': honoServer.fetch,
+    '/notifications/*': honoServer.fetch,
+    '/icons/*': honoServer.fetch,
+    '/events/*': honoServer.fetch,
     ...spaRoutes,
     '/api': honoServer.fetch,
     // A CLOSURE, deliberately, and not the bound `honoServer.fetch`.