step 3/4: sidecar routing keys become handles — NOT YET VERIFIED LIVE

Committed before restarting, deliberately: this changes the registration wire,
and the restart that proves it also bounces officer-claude-code, which is what
the session doing the work runs on. An uncommitted 25-file protocol change is
worse to inherit than one marked unverified.

`capabilities: ['music']` → `handles: ['music']` on the registration message,
across 20 sidecars, both plugins, the connector, the registry and the protocol
type. findSidecarByCapability → findSidecarHandling, waitForCapability →
waitForHandler.

The name: a sidecar already has `handleCommand`, so the list is literally what
it handles. `provider` was rejected — 390 existing uses and it already means
websocket door. `serves` was rejected — collides with HTTP serving, which
sidecars also do.

THIS IS A BREAKING WIRE CHANGE with no compatibility shim. A platform expecting
`handles` reads `undefined` from a sidecar sending `capabilities`, registers it
with an empty list, and every sendCommand finds nobody — chat, terminal and
music all fail with "No sidecar handling X is connected". So the whole estate
has to restart together; there is no rolling upgrade.

If it goes wrong: `git revert HEAD` and `pm2 restart all` again. The registry is
in-memory and nothing about this touches the database, so a revert is complete.

Found a fifth meaning of the word on the way, correctly named and untouched:
the pty sidecar's terminfo capability queries (XTGETTCAP escape sequences).
That is now five — permissions, the item store, routing keys, Lightning wallet
features, and terminfo.

tsgo clean, 797 tests, 787 pass, same 7. Not exercised against a live sidecar.

src/server.tsx

@@ -146,7 +146,7 @@ const handlers: Record<string, any> = {
   sidecar: sidecarWebsocket,
 };
 
-// Both doors into the platform, checked against the capability registry before either opens.
+// Both doors into the platform, checked against the permission registry before either opens.
 //
 // This throws rather than warns, and it throws HERE — before serve() — so a surface nobody has gated
 // cannot be reached even once. The HTTP half comes from hono.ts's own mount table and the socket half
@@ -283,14 +283,14 @@ async function upgradeWs(
       if (await isTokenBlacklisted(user.jti)) return new Response('Unauthorized', { status: 401 });
     }
 
-    // The capability backstop, applied to sockets. Everything above this line AUTHENTICATES — it proves
+    // The permission backstop, applied to sockets. Everything above this line AUTHENTICATES — it proves
     // who is calling and never asks what they may reach. That is why a Member with a valid token could
     // open a terminal here in the same minute it was 403'd on GET /api/tasks.
     //
     // This resolves against the same registry as the HTTP door rather than a parallel list, which is the
     // whole point: the two doors cannot disagree about what a role holds, because there is only one
     // declaration to read. `terminal`, `chat`, `task-runner`, `pipeline` and `desktop` are refused here
-    // by being `execution` capabilities, not by being absent from an array someone has to maintain.
+    // by being `execution` permissions, not by being absent from an array someone has to maintain.
     if (!(await isWsProviderAllowed(user.id, provider))) {
       return new Response('Forbidden', { status: 403 });
     }
@@ -316,14 +316,14 @@ async function upgradeWs(
 
     // The chat socket's owner-only refusal was removed on 2026-08-12, with `api/chat/chat.ts`'s in the same
     // commit — they were always one guard in two places. A member's turn now runs as their own Linux account
-    // with their own credential and their own transcripts; the capability check above is what gates it.
+    // with their own credential and their own transcripts; the permission check above is what gates it.
 
     if (provider === 'terminal') {
       const resolved = await resolveHomeDir(user.id);
       if (!resolved.ok) return new Response('Forbidden', { status: 403 });
       if (!resolved.isOwner) {
         const dbUser = await getUserById(user.id);
-        // A confined capability is only granted to an account with an OS user, so this should not happen —
+        // A confined permission is only granted to an account with an OS user, so this should not happen —
         // and if it ever does, refusing beats opening the owner's shell.
         if (!dbUser?.osUser) return new Response('Forbidden', { status: 403 });
         url.searchParams.set('osUser', dbUser.osUser);