step 4/4: the docs say permissions too, and capability means one thing again

44 files of prose — CLAUDE.md, AGENTS.md, TODO.md, 20 docs, both plugin design
documents, and the comment surface the earlier steps could not reach.

Applied against an explicit keep-list, not swept, because the word turned out to
have SIX meanings in this repository rather than the three the offscale doc
recorded:

  permissions          renamed (steps 1–2)
  $OFFICER_ROOT/capabilities/  KEPT — the item store, and now the only thing
                               the word means that is ours
  sidecar routing keys renamed to `handles` (step 3)
  Lightning wallet     KEPT — a domain term, and on the wire to the mobile apps
  terminfo queries     KEPT — XTGETTCAP, in the pty sidecar
  InvoiceShelf         KEPT — per-resource { write, bulkDelete } flags

The sweep still falsified two things, both caught by checking rather than by
review, and both in prose that discusses more than one meaning at once:

CLAUDE.md began claiming the item store lives at `$OFFICER_ROOT/permissions`.
It does not; that directory is on disk and full of skills and tools.

And the offscale doc's own note about the collision became
"Named `permissions`, NOT `permissions`" — a sentence that had eaten the thing
it existed to warn about.

Both restored, and the note rewritten to say what is now true: capability means
one thing of ours, and three that belong to somebody else's vocabulary.

Verified live after restart: self and admin permission endpoints 200, gated
route 200, agent-status 200, 9 grants intact with 6 permissions offered.
tsgo clean, 797 tests, 787 pass, same 7.

The rename is done. Four steps, no data lost, no client break that survived
the step it was introduced in.

plugins/music/PLUGIN.md

@@ -130,7 +130,7 @@ to `/music` remounts the host and reloads it.
 ## Two bugs, neither visible from reading
 
 **The app-store catalogue still listed music, and that would have blanked the screen.**
-`capabilityAvailability()` derives from `sidecar_installs`, and a _plugin_ never gets a row there — its
+`permissionAvailability()` derives from `sidecar_installs`, and a _plugin_ never gets a row there — its
 install state is `plugin_installs`. So `music` would have been permanently `unavailable`, which puts
 `/music` into `deniedRoutes`: dock tile withheld, screen blank, on a server where the plugin was
 installed, enabled and healthy.
@@ -150,7 +150,7 @@ so it finds `src/servers/plugins/` and not `plugins/`.
 ## Permissions
 
 One permission, `music`, and the key is deliberately unchanged from the registry entry it replaces — so
-every existing `role_capabilities` grant keeps meaning what it meant, and `can('music')` keeps resolving
+every existing `role_permissions` grant keeps meaning what it meant, and `can('music')` keeps resolving
 for the overlay. Renaming it would have been a silent data change.
 
 The old entry carried `personal: ['/favorites', '/now-playing', '/playlists', '/queue']`. A manifest has
@@ -224,7 +224,7 @@ The runbook's table, run against `platform.officer.dev` rather than reasoned abo
 | the API                         | `/api/music/manifest` 200, `/api/music/favorites` returns per-user JSON                                                                                  |
 | range requests                  | full 200 + `Accept-Ranges`; `bytes=100-199` → **206**, correct `Content-Range`, exactly 100 bytes; unsatisfiable → **416**; `../../etc/passwd` → **400** |
 | the screen                      | route generated in `Plugins.gen.tsx`, panels in the built bundle, `PluginScreen` wraps `WorkspaceView`. Structural — not eyeballed in a browser          |
-| dock                            | tile present in `/api/user/capabilities`; `/music` in `routes`, not in `deniedRoutes`                                                                    |
+| dock                            | tile present in `/api/user/permissions`; `/music` in `routes`, not in `deniedRoutes`                                                                     |
 | permissions page                | `music` listed among the grantable                                                                                                                       |
 | disable                         | route 404s, sidecar `stopped`, **rows survive**                                                                                                          |
 | enable                          | 200 again, sidecar online, favourites still there                                                                                                        |
@@ -247,7 +247,7 @@ exist before.
 Found 2026-08-15, after the extraction landed, by reading the code rather than by anything failing.
 
 `MusicBrowser.tsx` lists folders with `GET /file-browser/ls`, not through the music sidecar
-(`MusicBrowser.tsx:63,81`). `/file-browser` belongs to the **`files`** capability, and `files` is
+(`MusicBrowser.tsx:63,81`). `/file-browser` belongs to the **`files`** permission, and `files` is
 **`confined`** — so:
 
 - a member granted `music` but not `files` gets a working player, working favourites, and an **empty
@@ -266,7 +266,7 @@ Three possible shapes, none chosen:
    listing behind the `music` permission where it belongs, and the plugin stops needing `files` at all.
    Most self-contained, and the most work.
 2. **The manifest declares a permission dependency**, and the platform refuses the grant or warns. Honest,
-   but it makes one plugin's grant conditional on another capability, which is new machinery.
+   but it makes one plugin's grant conditional on another permission, which is new machinery.
 3. **Leave it and document it** — a member needs `files` too. Cheapest, and it quietly ties a music grant
    to a Linux account, which is a much bigger commitment than the owner is agreeing to on that page.
 
@@ -280,5 +280,5 @@ Not tonight's call.
   manifests, and the self endpoint concatenates both. One when the store is rebuilt on the plugin system.
 - **`src/servers/sidecar/protocol.ts` still declares `music:server`** per sidecar. Generalising the union
   to `` `${string}:server` `` is the better fix and is pending for the whole protocol.
-- **The cliamp sockets are claimed by no capability**, and are served. Now pinned by a test in
+- **The cliamp sockets are claimed by no permission**, and are served. Now pinned by a test in
   `registry.test.ts` rather than left to be rediscovered — closing it is the totality work.

plugins/music/manifest.ts

@@ -53,7 +53,7 @@ export const manifest: PluginManifest = {
   // One permission gating the whole surface, grantable per role at read or write like every other.
   //
   // The key is `music` and that is not incidental: it is the key the platform's own registry used until
-  // this extraction, so every existing `role_capabilities` grant keeps meaning what it meant, and the
+  // this extraction, so every existing `role_permissions` grant keeps meaning what it meant, and the
   // overlay's `can('music')` keeps resolving. Renaming it would have been a silent data change.
   //
   // `[open]` What a member's grant MEANS here is this plugin's own job and is not finished. Favourites,

plugins/music/web/MusicPlayerHost.tsx

@@ -123,7 +123,7 @@ export const MusicPlayerHost = () => {
   // Restore the saved "currently playing" on first load — paused, at its position — so a reload/return
   // lands back on the track. Skipped when a queue already exists (an in-app nav kept player state).
   //
-  // Also skipped without the `music` capability. This host is mounted by the shell for every account, so it
+  // Also skipped without the `music` permission. This host is mounted by the shell for every account, so it
   // used to reach for `/music/now-playing` on a member's very first paint and 403.
   useEffect(() => {
     if (restoredRef.current) return;