v0.2.2 — fix redo-loop misfire on slow send pipeline

Fix

Stops the redo workaround (added in 0.2.0 as 7b54098) from misfiring on ChatGPT's now-slower send pipeline, which was causing every multi-turn / Pro / attachment-heavy call to either silently branch the conversation or fail with trigger-failed [no-button] while the message was still successfully sent server-side.

Root cause

The original SEND_CLAIM_WAIT_MS=6000 assumed a short prepare dance. Verified 2026-05-01 by sniffing the actual pipeline:

+9.1s   POST /backend-api/conversation/init
+11.6s  POST /backend-api/f/conversation/prepare
+12.2s  POST /backend-api/conversation/experimental/generate_autocompletions
+14.9s  POST /backend-api/f/conversation                       ← what rosetta waits for
+14.9s  POST /backend-api/sentinel/chat-requirements/prepare
+15.3s  POST /backend-api/sentinel/chat-requirements/finalize

Click-to-/f/conversation is commonly 15–25 s even for trivial prompts, easily 30 s+ on multi-turn Pro with attachments. The 6 s redo would fire mid-pipeline; the redo's click landed when the button had already flipped to stop, raising no-button while the original send completed anyway — orphaning a sibling branch in the conversation tree and returning no result to the caller.

What changed

• Intercept /f/conversation/prepare via Fetch.enable as a "send pipeline in flight" signal (pass through unmodified, just flip prepareSeen)
• Replace the 6 s × 3-attempt redo loop with a 25 s base wait, bounded by 120 s total
• Only redo when both signals say the click was lost: prepare not seen and the send button is still visible+enabled. Either signal alone keeps us waiting
• Add isSendButtonStillClickable() probe used as the second redo guard
• Dump composer + button-region DOM to stderr on no-button failures for offline forensics
• Bump README protocol-tracking date to 2026-05

Compatibility

No API changes. Existing runConversation / MCP consult calls unchanged.