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>

docs/nextcloud-replacement.md

@@ -135,8 +135,9 @@ Rationale for not reusing the account password: it ends up typed into a phone, s
 account manager in recoverable form, and synced to whatever backs that phone up. One password per
 device, revocable per device, is the whole point.
 
-The single-user invariant holds — every app password belongs to the owner. `user_id` is there for
-referential integrity, not multi-tenancy.
+`user_id` was described here as "referential integrity, not multi-tenancy". That is no longer true:
+since 2026-08-07 `calendar` is a **grantable** capability, so an app password can belong to a member
+and the column decides whose collection tree Radicale serves. It is load-bearing.
 
 ---
 
@@ -182,8 +183,9 @@ Naming these now so they do not creep in later:
 - **iTIP/iMIP scheduling** — sending invitations and processing RSVPs by email. Genuinely complex, and
   a single-user personal calendar mostly consumes invitations rather than issuing them. Revisit only
   on a concrete need.
-- **Sharing, ACLs, federation** — single-user is a hard invariant of this platform. There is nobody
-  to share with.
+- **Sharing, ACLs, federation** — still out of scope, but the reason weakened on 2026-08-07. Members
+  can now hold `calendar`, so there is somebody to share with; what is missing is any notion of one
+  account granting another access to its own collection. Revisit on a concrete need.
 - **Reimplementing RRULE on the server.** The sidecar stores what the client sends. Expansion happens
   where it is displayed, using a library.
 - **A NextCloud-compatible API.** Nothing needs to pretend to be NextCloud. The standards are the