Redact thread on merge success even if deploy fails; add clear command

A merge whose post-merge deploy failed left the review thread orphaned (redaction was gated on deploy success). Now the thread always redacts on merge success and the deploy-failure warning is posted at top level so it survives. New clear/resolve command redacts an orphaned thread without touching the PR.

AGENTS.md

@@ -43,14 +43,17 @@ flat JSON in a writable `state/` mount.
 - **Onboard a repo:** create a Matrix room named like the repo, invite this bot → it auto-joins,
   maps the room to `<owner>/<roomname>` (+ `~/Projects/<roomname>` on the Mac), and posts an
   onboarding message. Pick review agents in-chat: `agents +reviewer +security -adjudicator`.
-- **In a review room:** `merge` / `reject` (inside a PR's thread, or `merge <n>` by number), `yes`/`no`
-  to confirm a merge, `agents …` to toggle the subagent panel.
+- **In a review room:** `merge` / `reject` / `clear` (inside a PR's thread, or `<cmd> <n>` by number),
+  `yes`/`no` to confirm a merge, `agents …` to toggle the subagent panel. `clear` (alias `resolve`)
+  redacts an orphaned thread without touching the PR.
 
 ## Layout
 
 - `src/bot.py` — the bot: matrix-nio sync; auto-join + in-room auto-map (room→repo by name); a Gitea
   poll loop per mapped repo; threaded `claude -p` review (subagent panel); merge/reject/deploy
-  in-thread; whole-thread redaction on resolve (server-enumerated, restart-proof).
+  in-thread; whole-thread redaction on resolve (server-enumerated, restart-proof) — a merge always
+  redacts (a failed post-merge deploy leaves a top-level warning, not an orphaned thread); `clear`
+  redacts without touching the PR.
 - `config.example.toml` — homeserver, `[mac]` (ssh alias + the reused matrix-bridge wrapper paths),
   `[gitea]` (api_base/owner/verify_tls), `[defaults]`, optional `[repo.<name>]` deploy overrides.
 - `.env.example` — `MATRIX_*` + `GITEA_TOKEN` (real `.env` gitignored).
@@ -82,14 +85,19 @@ revisit this — local inference via Spark Control would be the path.
 
 ## Current state
 
-**Built + DEPLOYED 2026-06-28; awaiting first real PR.** Bot is running on the Spark (`docker compose
-up -d`), `@reviewer` is in a review room, the room is mapped to a repo, and the subagent panel is
-configured in-chat. Core flow ported from matrix-bridge (D15–D19), generalized to multi-repo + the
-panel. **Not yet exercised on a live PR** — next session: open a test PR and confirm the chain
-(threaded review → `merge`+`yes` → force_merge → auto-publish → thread redacted). **The one unproven
-bit:** headless `claude -p` spawning the reviewer/adjudicator/security subagents (Option B) — if it's
-flaky, fall back to bot-orchestrated separate `claude -p` runs (the rejected alternative; see ROADMAP
-Phase 2). **Deploy gotchas hit this session:** the Spark needs a *dedicated* per-repo Gitea deploy
-key + a `Host` alias (the default `immense-voyage.local` block uses matrix-bridge's key) — clone via
-the alias; Gitea won't reuse one SSH key across repos' deploy keys. A Spark Control tile is captured
-in the inbox.
+**LIVE and proven.** Bot runs on the Spark (`docker compose up -d`), `@reviewer` maps each review room
+to its repo, and the subagent panel is configured in-chat. Proven end-to-end on **ten31-site PR #4**
+(2026-06-28): threaded review → `merge` + `yes` → force_merge → auto-publish → thread redacted — and
+the previously-unproven bit, **headless `claude -p` spawning the reviewer/adjudicator/security
+subagents, works**. The ten31-site colleague is onboarded; the pipeline is in steady use.
+
+**This session's hardening (NOT yet on the Spark — needs a redeploy: `git fetch && git reset --hard
+origin/master && docker compose up -d --build`):** a merge now **always redacts** the thread on merge
+success; a failed post-merge deploy posts its "deploy manually" warning at **top level** so it
+survives the redaction instead of orphaning the thread (the bug PR #4 hit when the Mac was left off
+`master`). New **`clear`/`resolve`** command redacts an orphaned thread without touching the PR.
+
+**Deploy gotcha (still true):** the Spark needs a *dedicated* per-repo Gitea deploy key + a `Host`
+alias (the default `immense-voyage.local` block uses matrix-bridge's key); Gitea won't reuse one SSH
+key across repos' deploy keys. A Spark Control tile is captured in the inbox. **Next:** redeploy on
+the Spark, then clear ten31-site's orphaned PR #4 thread (reply `clear` in it, or `reject`).