Record the push watch as live and verified end to end

AGENTS.md

@@ -198,13 +198,20 @@ revisit this — local inference via Spark Control would be the path.
 up since 08-13 with zero restarts, and the poll loop is genuinely alive (two Gitea connections exactly
 60s apart — see the liveness recipe in Commands).
 
-**2026-08-21 — the collaborator push watch shipped.** `master` now carries code the Spark hasn't got
+**2026-08-21 — the collaborator push watch shipped and is LIVE on the Spark** (`e5a187b`, no redeploy
-yet, so **a redeploy is pending** (and the Spark's `config.toml` needs the new `[gitea] my_emails` +
+pending). Verified end to end in the real room, not just in tests:
-`[repo.ten31-brand]` keys, which are gitignored and live only there). Two independent reviewer passes
+- a real notice + assessment for jonathan's `75cc63d` (VERDICT: OK, panel off), and
-ran over it; the first found the batch being recorded only *after* its assessment (a crash would have
+- the owner's own `4230f30`/`d307bdd`, pushed while the watch was already running, recorded silently
-replayed the whole notice) and an all-clear line printable from a missing file list, the second found
+  with no notice — the identity filter proven on live traffic rather than a fixture, and
-untrusted PR/commit metadata sitting above the prompt's fence. All fixed, each with a mutation that
+- the record-before-assess ordering proven at runtime: the commit was already in `state/rooms.json`
-reproduces it.
+  while the assessment's `ssh mac-bridge` process was still alive.
+
+Two independent reviewer passes ran over it. The first found the batch being recorded only *after*
+its assessment (a crash would have replayed the whole notice) and an all-clear line printable from a
+missing file list; the second found untrusted PR/commit metadata sitting above the prompt's fence.
+All fixed, each with a mutation that reproduces it. The Spark's `config.toml` carries the new
+`[gitea] my_emails` + `[repo.ten31-brand]` keys (gitignored, so they live only there); the pre-change
+copies are at `~/gitea-review-bot/config.toml.bak-20260821` and `~/rooms.json.bak-20260821`.
 
 - **ten31-site** — proven end-to-end on PR #4 (2026-06-28: review → `merge` + `yes` → force_merge →
   auto-publish → redacted). **PR #5 "Update index.html" is still open**, reviewed 2026-06-30, its thread
@@ -222,11 +229,10 @@ reproduces it.
   hypothetical.
 
 **Next steps, in priority order:**
-1. **Deploy the push watch and watch one real notice land** (see the pending redeploy above).
+1. **Fix the orphaned-thread prune** (`src/bot.py` ~L594): the poll loop drops a PR's thread root from
-2. **Fix the orphaned-thread prune** (`src/bot.py` ~L594): the poll loop drops a PR's thread root from
    state when the PR leaves the open list *without redacting*, so a PR merged or closed in the Gitea web
    UI strands its thread and `clear` can no longer reach it. More likely to bite now with two rooms.
-3. **`/triage` the 3 untriaged inbox items** tagged for this repo — adjudication never reads the inbox, so
+2. **`/triage` the 3 untriaged inbox items** tagged for this repo — adjudication never reads the inbox, so
    their content is still unknown here.
-4. With a 2nd repo mapped, ROADMAP Phase 3's verify is unblocked: next time both rooms have open PRs at
+3. With a 2nd repo mapped, ROADMAP Phase 3's verify is unblocked: next time both rooms have open PRs at
    once, watch a cycle (`docker compose logs -f`) for a long review head-of-line-blocking the other room.