Duplicate proactive auth-refresh scheduling corrupts OAuth token, requires re-login every ~6 hours

Summary: Corrupted OAuth token (Authorization header) requiring re-login every ~6 hours, starting right after a silent auto-update.

Version: silently updated 2.1.225 → 2.1.226 on 2026-08-08 despite settings.json having "autoUpdates": false (see ~/.claude/.last-update-result.json).

Symptom:

API Error: Header 'Authorization' has invalid value: 'Bearer sk-ant-oat01-...'

The token string itself contains an embedded newline + leading whitespace mid-value. claude logout && claude login fixes it temporarily, but it recurs roughly every ~6.3 hours.

Evidence: ~/.claude/daemon.log shows the proactive auth-refresh being scheduled TWICE at the identical millisecond from a single daemon start:

[2026-08-07T23:58:47.190Z] [supervisor] auth: scheduling proactive refresh in 22757s
[2026-08-07T23:58:47.191Z] [supervisor] auth: scheduling proactive refresh in 22757s

This looks like a duplicate timer registration — two refresh writers hitting ~/.claude/.credentials.json around the same moment would explain the interleaved/corrupted token.

Contributing factor: I run Remote Control continuously. At the time this started, I had a --serve server process alive since 2026-08-06 (pre-dating the update), a --bridge process, and a ccd-cli remote worker pinned at v2.1.222 — all concurrently sharing ~/.claude/.credentials.json with a local CLI now at v2.1.226. Version skew across long-lived components that each may refresh the token independently seems like a plausible trigger. (Killing and letting the stale server/bridge processes respawn on the current version is my workaround while this is open.)

Question: Is proactive-refresh scheduling supposed to be idempotent per daemon instance? Should long-lived Remote Control server processes restart after a CLI auto-update instead of continuing to run stale?