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.

docs/mobile-api-keys.md

@@ -139,7 +139,7 @@ will not meet it.
 | **401** | The credential is dead — revoked, expired, or never valid.           | Clear it, send the user to the login screen.                                               |
 | **403** | The credential is **fine**; this account may not reach this feature. | **Do not clear the credential.** Show "not available for your account" and stay signed in. |
 
-Clearing a good key on a 403 is the failure mode to avoid: it turns a member's missing capability into a
+Clearing a good key on a 403 is the failure mode to avoid: it turns a member's missing permission into a
 logout loop they cannot escape, because signing in again produces a credential with the same 403.
 
 A revoked key goes 401 on the very next request — revocation is checked in SQL at lookup, not cached.
@@ -153,7 +153,7 @@ decides everything after.
 
 - **The owner** (user 1) reaches everything.
 - **Any other account** reaches only what its role has been granted, and **can never** reach the
-  `execution` capabilities — terminal, chat, tasks, files, desktop, browser. Those run as the owner's OS
+  `execution` permissions — terminal, chat, tasks, files, desktop, browser. Those run as the owner's OS
   user in the owner's home; they are refused structurally, not by policy.
 
 Verified: a member's key returns the same status as that member's JWT on every route tried, 403s
@@ -233,7 +233,7 @@ both, so the endpoint cannot be used to discover whether an id exists.
 
 ## Not built
 
-- **Scopes.** A key cannot be narrowed to a subset of its holder's capabilities. The column and the check
+- **Scopes.** A key cannot be narrowed to a subset of its holder's permissions. The column and the check
   are a small change (`resolveApiKey` in `src/servers/auth-token.ts` is the one place), but nothing is
   there today. Design as if every key is full-authority, because it is.
 - **A key-management screen in the mobile apps.** Only the web UI can list and revoke. Fine to leave —