feat(chat): agent panels — named Claude panels that can hand work to each other

Committing work that was left uncommitted in the shared tree. I did not write it;
I reviewed it in full, verified it against the running system, and am landing it at
the owner's explicit request because no one currently owns it.

This REPAIRS master. `useAgentPanel.ts` shipped in dbe585f and calls
`/chat/agent-panels`, but `registerAgentPanelRoutes` existed only in the working
tree — so on master as pushed, every one of those calls 404s. The feature has been
half-landed since that commit.

What it is. A panel on a dashboard can be given a name ("frontend", "code-reviewer").
Naming it mints two things: a `sessionKey`, which is the panel's permanent continuity
(it keys the sidecar's on-disk resume map and `chat_session_events`, so the same panel
reopens the same Claude session), and a `handoffToken`, a bearer credential scoped to
exactly one verb. The agent in that panel is then addressable by name, and can pass
work to a peer on the same dashboard over `/api/agent-handoff`.

Three doors, deliberately separate:
  - `/chat/agent-panels` (browser, session-authed) — name / list / rename / forget.
    Mounted on the chat router rather than given its own prefix: these routes create
    and name Claude sessions, which is authority `chat` already grants. A second
    top-level mount would have meant a second capability entry claiming the same
    thing under a different name.
  - `/api/agent-handoff` (agent, token-authed) — peers and send. Unprotected by the
    session middleware and exempted in `capabilities/totality.ts` with its reasoning
    written down, because the caller is a subprocess with a token, not a browser with
    a cookie.
  - The transcript stays where transcripts live. DELETE forgets the address and the
    panel's claim on the session; it does not touch ~/.claude/projects.

Security, as verified rather than assumed:
  - The sender is derived from the token, never from the request body — there is no
    `from` field on the wire, so it cannot be forged.
  - Every lookup is scoped to the token's `userId` AND `dashboardId`, so an agent can
    only see and reach peers on its own dashboard.
  - `toAgentPanelView` strips `handoffToken` and `userId`, and it is the only shape
    the browser routes return. Confirmed by reading every return path.
  - Live-tested: a real token on `GET /api/agent-handoff/peers` returns 200 with
    correctly scoped peers; a bogus one returns 401.

Two judgement calls in the code worth knowing about, both already commented at their
site: the introduction turn inlines the handoff token into a runnable curl (a
single-owner MVP trade), and `agent_panels` carries no FK to `dashboards.id` because
that primary key is mid-rework to a composite.

Schema uses `uniqueIndex` throughout, never `unique().on(...)` — the rule that exists
because drizzle-kit mis-diffs named composite unique constraints and re-creates them,
which is what wiped seven tables on 2026-08-03.

NO `bun db:push` IS NEEDED. `agent_panels` is already live in Postgres with 6 rows;
the schema file is catching up to a database that already has it.

Verified: `bunx tsgo` clean, `bun test` 538 pass / 0 fail across 35 files.

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

src/servers/hono.ts

@@ -22,6 +22,7 @@ import { taskLogsRouter } from './api/task-logs/task-logs';
 import { router as fileBrowserRouter } from './api/file-browser/router';
 import { musicRouter } from './api/music/router';
 import { vaultRouter } from './api/vault/router';
+import { agentHandoffRouter } from './api/agent-handoff/router';
 import { slskdRouter } from './api/slskd/router';
 import { headscaleRouter } from './api/headscale/router';
 import { transmissionRouter } from './api/transmission/router';
@@ -103,6 +104,13 @@ honoServer.route('/api/waitlist', waitlistRouter);
 honoServer.route('/api/vault', vaultRouter);
 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
+// session running a curl, and it carries a per-panel bearer token rather than a platform session JWT,
+// so userMiddleware would 401 it and a capability lookup would have no account to resolve. The token
+// identifies exactly one agent panel and authorises exactly one action: deliver a prompt to a named
+// peer on that panel's own dashboard. See servers/api/agent-handoff/router.ts.
+honoServer.route('/api/agent-handoff', agentHandoffRouter);
+
 // CalDAV/CardDAV for phones and desktop clients — mounted TOP-LEVEL for the same reason the vault is:
 // DAVx5, iOS and Thunderbird authenticate with HTTP Basic on every request and have nowhere to put a
 // platform JWT, so userMiddleware would 401 them. The credential is a scoped DAV app password; see
@@ -209,7 +217,14 @@ export const PROTECTED_API_PREFIXES: string[] = PROTECTED_MOUNTS.map(([prefix])
  * Mounted above the account gate, and so exempt from capability checks — see EXEMPT_API_PREFIXES in
  * capabilities/totality.ts, which has to justify each one.
  */
-export const UNPROTECTED_API_PREFIXES: string[] = ['/auth', '/landing-page-data', '/waitlist', '/vault', '/sidecar'];
+export const UNPROTECTED_API_PREFIXES: string[] = [
+  '/auth',
+  '/landing-page-data',
+  '/waitlist',
+  '/vault',
+  '/sidecar',
+  '/agent-handoff',
+];
 
 honoServer.route('/api', protectedRouter);