Keep trying an overnight sign-in instead of giving up on it

[popen2]

A refresh that came due while nobody was at the machine ended the same way every
time: the page needed the user, Frost showed a login window (or opened a browser
tab) into an empty room, AWS expired the device code ten minutes later, and
scheduleAfterFailure() then stopped refreshing altogether and raised "Sign-in
Needed". By morning that notification pointed at a code that had died in the
night, the tray said "Sign-in needed" with nothing scheduled, and credentials had
been expired for hours — with Auto-open browser set, which is the setting that
asks Frost not to leave it to the user.

Not retrying was the right fix for #83 (a login page every half second, a tab a
minute in default-browser mode) and the wrong one for this. The pile-up came from
retrying visibly with nobody there, so that is what changes.

What this does

Continuous refreshing is the premise of the app, so there is no backoff of any
kind on a login nobody finished. AWS keeps a device code alive for about ten
minutes; when one dies the next sign-in starts at once, all night, and the pacing
is AWS's rather than ours.

• An unattended login is held, not shown and not abandoned. When the page
  turns out to need a person and nobody is at the machine
  (powerMonitor.getSystemIdleTime() against AWAY_IDLE_SEC), the attempt is
  parked: nothing on screen, and the page keeps being driven — so a slow
  identity provider or a dropped network still completes the refresh with nobody
  the wiser. The live page is handed over the moment somebody is there, on the
  next poll. HANDOVER_MIN_CODE_LIFE_MS keeps a code with seconds left from
  being handed to a user who would watch it die; the replacement is immediate, so
  they get a fresh page instead.
• Presence is read wherever it matters, not captured once per run: a
  ten-minute login can start with nobody there and end with the user watching it.
• MIN_LOGIN_CYCLE_MS (30s) is the only floor, and is not a backoff — it
  never grows, and nothing waits for it unless a login fails the instant it
  starts, which would otherwise spin attempts as fast as AWS could refuse them.
• A parked run stays reachable. It holds isWorking, which would have made
  "Refresh now" and the hotkey no-ops all night and the tray read "Refreshing…"
  while a page sat waiting for a password. A refresh the user asks for now shows
  the login Frost is holding, and the tray says Sign-in needed — waiting for
  you.
• The "Sign-in Needed" notification is gone. It existed because Frost stopped
  trying and that was invisible; the replacement login is the notice now, and a
  notification on top of it is the thing this change is meant to stop.
• Notification mode and manual approval cannot get through unattended at all,
  so they no longer burn a device code to find that out: Frost waits for the user
  and starts then, recording one run rather than one every half minute.
• Only the user ending a login themselves — closing the window, refusing it at
  the identity provider — still stops the replacements.
• retryDelayMsAfterError() splits into errorRetryDelayMs() (unchanged 1m→30m
  for failures with no login page involved) and nextLoginAttemptDelayMs(), with
  loginRetryAction() deciding each tick. AGENTS.md and the docs pages follow.

The first commit here kept Frost trying but on a 5-minute-to-hourly backoff, and
ended an attempt as soon as it needed a human; the second replaces both with the
above. Reviewing the second commit alone is enough to see the final behaviour.

Verification

npm run build, npm run lint, and a headless harness driving dist/aws-sso.js
against stubbed electron (including powerMonitor idle time), a faked SSO OIDC
client and a fake clock: 53 checks over ten scenarios, plus the real
dist/tray.js rendering the held-login label.

• Eight simulated hours away with a page that needs a human: 46–49 device codes,
  worst gap between attempts 10m30s (the code's life plus the poll that notices),
  nothing shown, nothing notified, and the login page appears 10s after the first
  keypress.
• A slow identity provider coming through mid-hold completes the refresh
  unattended.
• Six hours away in default-browser mode: zero tabs, then exactly one when the
  user returns.
• Notify mode, four hours away: zero device codes, one run.
• Against main, the same night ends with one dead login page, one notification,
  and no sign-in until the user presses the hotkey.

Costs, deliberately accepted: a hidden login window and its 400ms approval scan
live continuously while a login is held rather than only during a refresh, and
the Activity page gains an entry per device code (~6/hour) while a machine is
away with a sign-in that needs a human.

Not checked here: real notifications, a real tray, and idle-time reporting on a
real desktop — the harness stubs all three. On a Linux session where
getSystemIdleTime() is unimplemented it reports 0, which reads as "somebody is
here", so those sessions get the visible login page rather than a held one.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PBe4cVzZUazesEcLLaktV4