hookdeck login: guest-upgrade poll is aggressive (fixed 2s, no backoff) and re-implements shared polling

[leggetter]

Summary

waitForGuestUpgradeCompletion (pkg/login/client_login.go) polls GET /cli-auth/validate on a fixed 2s interval with no backoff (up to 120 attempts / ~4 min) while hookdeck login waits for a guest sandbox to be claimed. Each poll triggers two tracked server events (CLI API Call via middleware + Validated CLI Client), so a slow claim floods analytics — ~185+ events in a couple of minutes were observed during testing.

Details

The CLI already has a shared poller, pollForAPIKey (pkg/hookdeck/auth.go), with adaptive backoff + rate-limit handling, used by both standard device login and GuestSession.WaitForAPIKey. The guest-upgrade wait re-implements polling instead of reusing it:

const guestUpgradePollInterval = 2 * time.Second
const guestUpgradeMaxAttempts   = 2 * 60
for attempt := 0; attempt < guestUpgradeMaxAttempts; attempt++ {
    response := ValidateAPIKey()      // GET /cli-auth/validate
    if !response.UserIsGuest { return response }
    time.Sleep(guestUpgradePollInterval)
}

No backoff, no rate-limit handling, and it targets a heavily-tracked endpoint.

Proposed fix

Extract the poll loop (interval + calculateBackoff + rate-limit reset) into a generic helper that takes a stop predicate, and have both pollForAPIKey and the guest-upgrade wait use it — so the guest-upgrade poll inherits backoff. Minimal alternative: add calculateBackoff to the guest loop and widen the base interval.

Context

Found while verifying PostHog tracking for the guest CLI login work (core #5233 / cli #306). A core-side fix (server-side $process_person_profile: false for guests) makes these poll events anonymous (cheaper), but does not reduce their count — that requires this CLI-side change.