#9515: fix(web): retry WhatsApp 515 restart up to 3 times with delay

## Problem The WhatsApp login flow only allowed a single restart attempt after a 515 error ("own on stream" / restart required after pairing). If the retry also failed with 515, the login state was cleaned up and subsequent polls returned "No active WhatsApp login in progress" indefinitely — the polling modal stayed open but never recovered. ## Changes - Replace boolean `restartAttempted` with `restartCount` (max 3 retries) - Add 1.5s delay between disconnect and reconnect (server cooldown) - Reset login TTL on each retry so retries have enough time ## Testing Existing test passes (adjusted for the new retry counter and delay). <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates the WhatsApp web QR login retry logic for disconnect status `515` by replacing the one-shot `restartAttempted` flag with a `restartCount` capped at 3, adding a 1.5s reconnect delay, and resetting the login TTL (`startedAt`) on each retry so subsequent polling has enough time to complete. The change is contained to `src/web/login-qr.ts`, specifically the `restartLoginSocket(...)` helper invoked from `waitForWebLogin(...)` when `login.errorStatus === 515`. <h3>Confidence Score: 4/5</h3> - This PR is close to safe to merge but has a race that can resurrect a stale login/socket during the added retry delay. - Logic is localized and the retry counter/delay are straightforward, but `restartLoginSocket` now introduces an awaited delay without any cancellation/active-login check, and it mutates the `login` object after the delay. That creates a concrete stale-reference hazard if the login is reset/replaced while waiting. - src/web/login-qr.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->