Making re-auth proactive: fire ahead of the 8h wall

[jlrobins]

• Goal: turn child 6's reactive re-auth into a proactive one for interactive sessions, so a
  live query is never ambushed by the wall — the re-login fires ahead of time, while idle.
• Scope (in): the child-7 daemon, which already wakes near token expiry, also watches
  refreshTokenAbsoluteExpiresAt and fires child 6's reauthenticate() (or the registered callback)
  ahead of the wall while idle; once-per-holder, observed by every Connection. Often silent —
  if the browser's Auth0 SSO session is still alive, the re-auth round-trips without a prompt.
• Out of scope: the re-auth mechanism + reauth= policy knob themselves (child 6); the default
  reactive behaviour is unchanged; unattended multi-day processes stay out of scope by design (use
  API keys).
• Depends on: children 6 (the reauthenticate() mechanism it fires) + 7 (the daemon it fires
  from).
• Prior art: the wall constants — ide-sidecar absolute-lifetime-seconds: 28800 (8h) +
  hasReachedEndOfLifetime() (which stops refresh and signals re-auth-needed, NONE / FAILED);
  mcp-confluent oauth/token-lifetimes.ts (8h abs / 4h idle) + AuthContext.refreshTokenExpired(),
  with transient classification in oauth/errors.ts (MAX_CONSECUTIVE_TRANSIENT_FAILURES = 50). But
  neither fires re-auth proactively — ide-sidecar signals, mcp's ensureLoggedIn() re-logs
  lazily on next use (the reactive path child 6 mirrors). Firing ahead of the wall is our own;
  #399 never faced it (its client-credentials source has no browser step to schedule).
• Sized right: a bounded enhancement teaching the [optimization] Proactive refresh daemon #157 daemon to watch the absolute wall and
  call#156's mechanism; can land any time after children Graceful re-authentication: in-place recovery + reauth= policy #156, [optimization] Proactive refresh daemon #157.