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/sidecar-app-store.md

@@ -16,7 +16,7 @@ Three things are already true, which is why "nothing exactly blocks it":
 - **Every API route stays mounted regardless of which sidecars run.** The light profile's own comment
   states it: features whose sidecars are absent report themselves unavailable rather than disappearing.
   So the app store never needs to mount or unmount routes.
-- **Officer already spawns nothing.** Sidecars are PM2 peers that dial in and register by capability.
+- **Officer already spawns nothing.** Sidecars are PM2 peers that dial in and register by permission.
   Installing one is starting a process, not teaching officer about it.
 - **`service_connections` already solves the multi-user case**, including the part nobody would get
   right independently — see below.
@@ -88,7 +88,7 @@ health checks already correct, so "install Gitea" does not become a tutorial.
   platform/      the app
   data/          DATA_PATH
   dockers/       services the app store provisioned   <- exclusively ours
-  capabilities/  the file-based item store
+  permissions/  the file-based item store
 ```
 
 `OFFICER_ROOT` is derived as the parent of `DATA_PATH` rather than configured separately — a second
@@ -239,7 +239,7 @@ Two things it needs before third parties touch it:
 
 What a plugin author is promised, and bound by. To be written properly; the shape is:
 
-- **Register** by name + capabilities over `/api/sidecar/register`; be reachable by capability.
+- **Register** by name + permissions over `/api/sidecar/register`; be reachable by permission.
 - **Declare** an ID, an install shape, a compose template (if it provisions), a config prompt, and a
   schema.
 - **May reference** `users.id`, and use `service_connections` under its own ID.