let the extension use the bare officer url, no path

Follow-up to the /vaultwarden mount: the suffix is superfluous if officer can tell a
bitwarden client apart, and it can.

Most of vaultwarden surface does not collide at all — /identity, /notifications, /icons and
/events belong to it and to nothing here, so those are served at the root by path alone, no
sniffing. Only /api collides (vaultwarden has /api/settings/domains, officer has
/api/settings), and there the client says who it is: every bitwarden client stamps
Bitwarden-Client-Name, older ones Device-Type.

Trusting a client header is fine because this is ROUTING, not authentication — the worst a
forged one achieves is reaching vaultwarden, which then demands its own credential exactly
as it would have. Nothing is authorised by it.

Registered before /api so it wins for a bitwarden client, and narrow enough that an ordinary
officer request never matches. Verified: /identity reaches the proxy, /api/sync with the
header diverts, /api/chat/models without it still answers 401 from officer, and the SPA is
untouched. /vaultwarden still works for anything that prefers an explicit path.

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

src/server.tsx

@@ -253,6 +253,13 @@ const server = serve({
     // 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,
+    // 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,
     '/': officerWeb,
     '/*': officerWeb,
     '/api': honoServer.fetch,