docs(records): CHAT-03 chartered, SetSpark approver owner, lead decisions 20 to 22

Jason approved CHAT-03 and gave Sage the SetSpark approver owner choice.
Decision 20 records the queue A1/A2 split. Decision 21 makes the SetSpark
fix Mosaic's through a Sage subagent and keeps the sanctioned pending:
approver markers so the cutover migration still works. Decision 22 charters
CHAT-03 with Dewey writing the brief. QUEUE row 5, DEFERRED and SESSIONS
updated.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

docs/plans/2026-09-26_lead-decisions.md

@@ -223,3 +223,43 @@ which stay with him. Each item names who decided it and what happened.
     approvals log. Jason named the SetSpark lead (T3 thread ac03938d), and
     Sage sent the approver validation request there. Mosaic needs no
     further change.
+20. **Queue as data splits into A1 and A2.** Filbert's plan (282fabbb) §1
+    left the split to Sage. A1 is the journal, lock, CLI and verify. A2 is
+    migration, render and dispatch. A1 lands first under five conditions:
+    - nothing runs against the canonical `.git`;
+    - QUEUE.md, AGENTS.md and TOOLS.md stay unedited;
+    - `scripts/test-queue.sh` is green at a HEAD with no `queue.json`;
+    - H is recorded before the canary;
+    - the fault layer is reachable only from tests.
+    Darkwing's A1 packet (build.md a1125ebd, manifest 4319695a) reports all
+    five met, and Filbert is reviewing it. When A1 lands, `queue` joins the
+    suite list. Genesis and the hook install stay Sage's bootstrap steps 2
+    to 4, after A2.
+21. **The SetSpark approver fix is Mosaic's, through a Sage subagent.**
+    Jason delegated the owner choice. The SetSpark lead can't touch
+    shared-signals. A Sage subagent writes the change in shared-signals
+    `stack/api`, Rocko reviews it, and Sage commits it to shared-signals main
+    following that repo's AGENTS.md. The subagent stopped at the
+    compatibility check. The strict `discord:` rule would refuse all 16
+    approvers on vault DEC-001 to DEC-008, which are sanctioned
+    `pending:<text>` markers (RECORDS.md, the decision template,
+    `validate_vault.py`), and that would block the cutover migration.
+    Ruling: keep the records convention. An approver is either a Discord ID
+    under the service's existing digit rule, shared with `validate_vault.py`
+    so the two can't disagree, or a `pending:` marker. The status condition
+    comes from `validate_vault.py`. Any other value gets a 422 with the value
+    not echoed. Opening an approval request is refused while any approver is
+    still pending. No data migration: the README gets a read-only query for
+    bad stored rows. DEC-009 stays as stored. If it was more than a test
+    record, a `record_update` through the Discord Sage writes its approvers
+    as `discord:` IDs, which bumps `proposal_version`, and request 1 closes
+    as stale on its next use. Deploying to VM 1022 is a host action and is
+    not part of this; it goes to Jason when the commit is pushed.
+22. **CHAT-03 chartered.** Jason approved it on 2026-09-26. Dewey writes the
+    brief, Filbert reviews it after A1, and Rocko does an adversarial pass
+    on control races and recovery. The brief must settle D1 and R3-1
+    (item 8), the Claude catalogue after B1, and the board send that can
+    become a Pi slash command. It names the CHAT-01/01C contracts by hash
+    and keeps path authority clear of queue A1/A2 and the ledger. Following
+    the plan page, Darkwing names the source author once the brief is
+    approved. No real seat migration.