fix(watchdog): detect idle opencode turns

cc-ci-plan/JOURNAL.md

@@ -591,3 +591,19 @@ session cc-ci-orchestrator-stale can be killed; recipe-mirrors org still private
 - Bounced only `cc-ci-watchdog` so it loaded the 14-phase queue without interrupting the active builder
   and adversary sessions. Verified `launch.sh status`: `cfold [10/14]`, builder/adv/watchdog RUNNING;
   watched sessions are still `opencode` for builder/adv/orchestrator.
+
+## 2026-06-12 ~21:45 — OpenCode watchdog idle detection fixed; stalled cfold loops recovered
+- Operator correctly observed the OpenCode loops had stalled after cfold M1. Root cause: watchdog
+  activity detection reused the Claude-oriented `ACTIVE_RE`, whose tokens (`▣`, `Build ·`) also appear
+  in OpenCode's static completed-turn footer. Finished OpenCode turns therefore looked active forever,
+  so the idle-stall branch never fired.
+- Fixed `launch.py` with an OpenCode-specific classifier: Claude still uses the old `ACTIVE_RE` path;
+  only `BACKEND=opencode` uses `opencode_pane_active()`, which checks the bottom prompt/status area
+  plus recent log mtime and ignores the static completed footer.
+- Added `launch.py selftest-opencode-activity` regression test. It proves: completed OpenCode footer =
+  idle, live `esc interrupt` footer = active, and a limit banner plus completed footer is not active.
+  `python3 -m py_compile cc-ci-plan/launch.py` and the selftest both passed.
+- Restarted `cc-ci-watchdog` on the patched code. Builder was already stuck in a stale input mode after
+  a manual nudge landed as a shell command, so restarted only `cc-ci-builder` via `start_agent`; it came
+  back on OpenCode GPT-5.4 and is actively planning the M2 sweep. Adversary accepted its nudge and wrote
+  `WAITING-UNTIL: 2026-06-12T21:55:28Z` while awaiting Builder's formal M2 claim.