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

- **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 #157 daemon to watch the absolute wall and
call#156's mechanism; can land any time after children #156, #157.