Browser-auth resilience follow-ups (UA derivation, write-path live test, setup-go bump) #31

Follow-ups from the v0.5.0 browser-auth release (design docs/plans/2026-05-30-headless-browser-auth-design.md, security review ...security-review.md):

1. UA/platform/version derivation (resilience, Important). defaultUserAgent is a fixed macOS Chrome 131 string; Sec-Ch-Ua-Platform/SetUserAgent.Platform hardcode macOS. Internally self-consistent + production-proven, but skews vs the launched Chrome's real navigator.platform/version (Linux on the runner). Derive UA + platform + version from the actually-launched Chrome (strip HeadlessChrome), then re-validate via the gocodealone-dns hover-live-auth-probe.yml before relying on it. Imperva's 2026 JA4 + UA-CH consistency checks make this the most likely future-break vector.

2. Write-path live validation. In-browser writes (CreateRecord/UpdateRecord/DeleteRecord/SetNameservers) are unit-tested against local httptest only — never live (test account has 0 domains; won't mutate production). Validate against a disposable domain before the migration phase relies on them.

3. setup-go@v5 Node-20 deprecation. The gocodealone-dns probe/import workflows emit a Node-20 deprecation warning (cutoff 2026-06-16). Bump the pinned action.

4. Email-2FA accounts are not CI-viable. Headless login needs TOTP (HOVER_TOTP_SECRET) or a pre-trusted persistent profile; email-default 2FA returns ErrEmail2FARequired. Documented; no code action unless we want to automate email-OTP (needs IMAP creds — out of scope).