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/opencode-phase0-review.md

@@ -36,7 +36,7 @@ for a follow-up that touches the socket contract, is the right split.
 `013e629` flipped `images: true` → `false` for OpenCode models, and the commit says "61 OpenCode models
 now decline, the three Claude ones still accept".
 
-**Nothing declines.** No code in `src/workspaces` or `src/apps` reads that capability — the composer's
+**Nothing declines.** No code in `src/workspaces` or `src/apps` reads that permission — the composer's
 image affordances are ungated. Grep for a consumer of the model's `images` field returns nothing:
 `InputArea`'s drop zone, the paste handler, and `AttachButton` all accept images regardless of model, and
 `useAttachments` collects them regardless.
@@ -47,14 +47,14 @@ which is worth having, but B4 described a user-visible lie and that lie is still
 
 Two ways to close it, and they are not equivalent:
 
-1. **Gate the composer on the capability.** Read the selected model's `images` flag and hide the drop
+1. **Gate the composer on the permission.** Read the selected model's `images` flag and hide the drop
    zone, the paste path and the attach-image button when it is false. Cheap. Makes the flag load-bearing,
    so the flip in `013e629` starts doing something.
 2. **Plumb images through `OpenCodeRunParams`** (currently Phase 4). Removes the limitation rather than
    surfacing it.
 
 (1) is the honest one-liner Phase 0 was for; (2) is the real fix. Doing (1) now costs nothing if (2)
-happens later — the gate simply stops firing once the capability is true.
+happens later — the gate simply stops firing once the permission is true.
 
 ---
 
@@ -99,7 +99,7 @@ finishes and had no effect on either test. Worth knowing it exists; not worth ch
 
 ## Suggested next work, in order
 
-1. **B4 properly** — gate the composer on the model's `images` capability (above).
+1. **B4 properly** — gate the composer on the model's `images` permission (above).
 2. **Delete the `AGENTS.md` injection and the stale one-project comment**, now that `--dir` is verified.
    This is Phase 1 work and it is the thing Andre most wanted gone.
 3. **Then the rest of Phase 1** — the dead `event-mapper.ts` and SSE machinery, the wrong path names in