Plan M4b: approvals over Mattermost in 15 tasks

Skeletons for new files only; existing files change by exact edits, so no task overwrites an
earlier one's work. Each task's tests were run against a reference built in order from master,
with the gate at each step and mutations checked; each skeleton compiles and fails its tests, and
every todo!() comment was read beside its signature. The reference is kept off this machine.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>

CLAUDE.md

@@ -15,7 +15,9 @@ merged: tool containers run from the image `deploy/tools-image.nix` builds, chec
 M4 is split: M4a (`gatewayd`, conversations over Mattermost, spec
 `docs/specs/2026-09-23-m4a-gateway.md`) is done and merged, reviewed in `docs/implementer-log.md`
 and checked end to end against the owner's Mattermost; no finding is open. M4b (approvals over
-Mattermost) is specified in `docs/specs/2026-09-24-m4b-approvals.md` (approved) and not yet planned. The owner's Mattermost settings and the
+Mattermost) is specified in `docs/specs/2026-09-24-m4b-approvals.md` (approved) and planned in
+`docs/plans/M4b/` (15 tasks, branch `m4b`); its reference is a bundle on straylight,
+`~/boxmaker-refs/m4b-ref.bundle`. The owner's Mattermost settings and the
 bot's token are in `mattermost.env` at the repository root: ignored by git, never committed, and
 the token is never printed.
 Straylight now serves Ornith as four slots over one 262,144-token pool; see