Harden Google self-heal follow-ups: atomic session saves, fast cookie-save retry, paced-repair observability

[MaxGhenis]

Non-blocking polish from PR #148's cross-family review (sol findings). #148 made maybePersistRotatedCookies rewrite session.json every ~5 minutes, which turned two latent nits into real exposure; the third item makes the fast-revocation detector visible in production.

1. Atomic SaveSession (internal/client/session.go)

SaveSession did a direct os.WriteFile of session.json — a crash mid-write could truncate the file holding the paired Google/WhatsApp/Signal credentials, and losing it costs a manual re-pair. It now writes a unique same-dir temp file (0600), fsyncs, and renames over the target, mirroring googlecookies.UpdateSessionCookies (plus fsync, so a power loss can't commit the rename ahead of the contents). Dir 0700 / file 0600 perms preserved; a unique temp name (not a fixed .tmp) keeps concurrent savers from installing each other's partial writes.

Test: concurrent writers + torn-read detector, verified to FAIL against the old os.WriteFile implementation (unmarshal: unexpected end of JSON input); plus a failed-save-keeps-previous-session test asserting no debris and intact prior contents.

2. Failed cookie-save retry (internal/client/events.go)

The throttle timestamp advanced before the save attempt, so a transient SaveSession failure wasn't retried for a full ~5-min interval. Resolution (the "OR" branch from the review, made explicit): the throttle still advances up front — these events arrive per message, so an unthrottled failure path would rewrite the session on each one — but a failed save pulls the next attempt in to interval/10 (~30s), and lastCookieHash stays untouched on failure so the retry still sees the pending rotation. The deterministic marshal-failure path deliberately keeps the full interval (commented).

Test: blocked-session-path harness proving one attempt per window, retry at interval/10 (not per event, not a full interval), and that the eventual successful save persists the rotation the failures skipped — verified to FAIL against the old advance-before-save semantics.

3. Paced-repair observability (cmd/google_supervisor.go → status surfaces)

pacedCount — the "cookies are being revoked within minutes" detector from the durability adjudication (theory A) — was test-only. Now:

• Log: each delayed repair emits a warn with wait, since_last_repair, min_interval, paced_total.
• /api/status: google.repairs_paced (omitempty — absent in the healthy 0 case). Wired via app.SetGoogleRepairPaceCounter; only the transport-owning daemon builds a repairer, so client/demo modes report 0. MCP client mode inherits it for free through RawStatus daemon-truth passthrough.
• MCP get_status: Repairs paced: N line, only when non-zero.
• Runbook: "Is revocation running fast?" section with the jq one-liner and the healthy-is-zero/climbing-means-churn interpretation, next to the heal-cycle description.

Testing

• go build ./... clean; touched packages (internal/client, internal/app, internal/tools, internal/web, cmd, internal/googlecookies) pass with -race -count=1
• Both regression tests demonstrated red against the pre-fix code before landing green
• Coordination check: open PRs Make conversation mutations visible in v2-primary and fix two send-path state bugs (rebuild W4-A) #145/docs(runbook): self-heal can loop forever + R8 v2-primary cutover traps #146 don't touch internal/client or the supervisor — no overlap with in-flight work

🤖 Generated with Claude Code