retire the single-user claim from the docs it outlived

CLAUDE.md asserted "single-user is a hard invariant, not a stage" while
users held six rows and role_capabilities held grants. Every doc that
repeated it is corrected here, in prose and in the code comments that
carried the same claim.

The accurate statement is narrower: one owner who bypasses every check,
other accounts holding only what their role is granted, and a set of
capabilities — terminal, chat, files, tasks, items, desktop, browser — that
are structurally ungrantable because they execute as the owner's OS user.

TODO.md gains a Multi-user section for what the read turned up: no way to
create a second account, dashboards.id colliding across users, authorize.ts
untested, pty/vault/opencode taking no identity, Radicale still owner_only.

claude-sidecar-isolation.md's open question is answered rather than left
open — the per-email spawn model is dead weight, because chat is an
execution capability and no second account can ever reach it.

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

SYSTEM_MONITOR_API.md

@@ -6,9 +6,13 @@ Everything the `/system-monitor` web screen renders, for building the same in th
 
 - Send the JWT as **`Authorization: Bearer <token>`**, or as **`?token=<token>`** in the query string
   (required for the SSE endpoints — `EventSource` can't set headers).
-- **Owner-only.** These routes are gated to the platform owner. Non-owner accounts (e.g. music-app
-  users) are confined to `/api/auth` + `/api/music` and will get `403` here. The full **officer-mobile**
-  client (which authenticates as the owner from an owner-allowed origin) has access; the music app does not.
+- **Owner-only.** These routes belong to the `server-admin` capability, which is `kind: 'admin'` and
+  therefore never grantable — a non-owner account gets `403` here whatever its role. The full
+  **officer-mobile** client (which authenticates as the owner) has access; the music app does not.
+- Note for anyone who read this before 2026-08-07: the old rule was that non-owner accounts were
+  confined to a hardcoded `/api/auth` + `/api/music`. That list is gone, replaced by per-role
+  capability grants. The *outcome* for these routes is unchanged — still owner-only — but the reason is
+  now the capability's kind, not a two-element array.
 - All responses are `application/json` except the two `/logs` endpoints, which are `text/event-stream`.
 
 ---