plan(ghost-pr): fold in upgrader's diagnosis — mysql 8.0->8.4 data-dir upgrade race (update_config.monitor too tight); PR#4 open

cc-ci-plan/plan-ghostpr-debug-fix.md

@@ -10,6 +10,19 @@ may be messy. This plan figures out what actually went wrong and leaves the ghos
 **Execute AFTER** the proxy VIP fix (so the infra confound is gone) and the current upgrade settles.
 Owner: orchestrator, or a focused `/recipe-upgrade ghost` re-run.
 
+## What the upgrader already found (2026-06-12 summary — start here)
+ghost 6.42.0→6.44.1 (+ mysql 8.0→8.4). PR is **recipe-maintainers/ghost #4**, open with an analysis
+comment. Three `!testme` attempts:
+- run 1 (2026-06-05): **PASS** at 6.44.0 + mysql:8.4 (under lighter load).
+- run 2 (2026-06-12): FAIL — **IPAM/proxy-VIP exhaustion** (infra; the [[proxy-vip-exhaustion-runbook]] issue).
+- run 3 (2026-06-12): FAIL — **a REAL issue**: Swarm `UpdateStatus=paused` on the **mysql 8.0→8.4
+  data-dir upgrade race** — the default 5s `update_config.monitor` is too tight for the mysql
+  data-dir migration under load, so Swarm marks the update paused/failed.
+The upgrader's suggested fix: add **`update_config.monitor: 300s`** (and likely
+`failure_action: continue` / a longer `start_period`) to the ghost **app** service so the mysql
+data-dir upgrade has time to converge. So the likely real fix is a small recipe-PR change to ghost's
+`update_config`, then re-verify — NOT a test change.
+
 ## Steps
 1. **Inventory the ghost PR state.** On recipe-maintainers/ghost: list open PRs — is there ONE
    upgrade PR or a DUPLICATE (two branches/PRs from the two ghost subagents)? Capture each PR's