Stop transient boot-time probe failures from permanently parking Signal needs_reauth

[MaxGhenis]

Problem

The Signal bridge recurrently latched a permanent needs_reauth park from a transient boot-time failure on a link that was actually valid. Three live episodes on the production install:

• 2026-07-20 — real signal-cli contention (pre-Make serve --mcp-stdio a transportless daemon client (fixes WhatsApp/Signal MCP fratricide) #149 mcp-stdio fleet)
• 2026-07-24, 2026-08-06 — no contention (transportless fleet, no signal-cli process, lsof on the config dir empty). The park held 12–22h with zero receipts while accounts.json was untouched since April; a single POST /api/signal/connect reconnected in ~5 seconds.

Root cause: runReceiveLoop's startup probe ran one listAccounts and treated an empty success (err == nil && account == "") as terminal proof of an unlinked account (last_error: "Signal account is not paired", needs_reauth: true → PollerFailureReauth → supervisor StateBlocked, forever). But listAccounts is local-only evidence: signal-cli racing its own account bootstrap at backend boot logs Ignoring <number>: User is not registered. and exits 0 with zero accounts — the exact signature the existing TestParseSignalAccountsIgnoresSignalCLIErrorOutput fixture documents.

Fix (all three prongs from the incident analysis)

(a) Retry before classifying — the receive-start probe now makes 3 paced in-generation attempts (each bounded to 30s; previously a single unbounded call) before any terminal classification. The observed boot race heals on attempt 2 without even churning a generation.

(b) Verify absence before demanding re-pair — an exhausted empty/invalid probe parks reauth immediately only when data/accounts.json also lists no account (locally gone — unchanged semantics, same signal_account_invalid fingerprint). While accounts.json still lists the link — both live false-park episodes — the generation exits transient (signal_account_probe_empty, retried on supervisor backoff), and only 3 consecutive disagreeing generations park, under a new distinct fingerprint signal_account_unreadable.

(c) The local-evidence park self-retests — signalSupervisorControl.StartParkRetest retries a signal_account_unreadable park every 15 minutes via RetryBlocked (one local probe; server traffic only on success). A lingering false park is now bounded to minutes instead of manual-connect-or-nothing.

Guardrails preserved

• Genuine server-side unlink still surfaces needs_reauth: a receive-loop not registered/authorization failed is server-backed evidence — it now takes 2 consecutive confirmations (still parks within seconds for a real unlink), keeps the signal_account_invalid fingerprint, and is never auto-retried.
• Nothing auto-unpairs, ever — unpair os.RemoveAlls the signal-cli dir including CDN-expired media.
• Pairing/upgrade parks and the manual /api/signal/connect escape hatch are untouched.

Tests

New coverage in internal/signallive/gate_test.go (StartPoller harness style) and cmd/signal_supervisor_test.go (supervisor-control fake-lifecycle style):

• boot-race empty probe retries and connects (no park, 2 probe calls)
• empty probe with stored account: transient × 2 → signal_account_unreadable park at streak 3
• a successful probe resets the streak
• single receive account-invalid glitch keeps the loop connected; consecutive ones park under signal_account_invalid
• the park retest exits an signal_account_unreadable park automatically and never touches a signal_account_invalid park
• existing probe-park test updated for the retry attempts (final classification unchanged)

GOWORK=off go test ./...: 33 packages pass; -race clean on internal/signallive, internal/bridgeadapters/signal, internal/bridge; go vet clean.

Runbook: new "Signal needs_reauth — read the fingerprint before believing the park" section documents the fingerprints and the debug flow.

🤖 Generated with Claude Code