refactor(runtime): extract rotation-proxy closure state (phase 2)

Phase 2 of the §4.1.3 rotation-proxy decomposition (follows the phase-1
carve, PR #532). The closure state inside startRuntimeRotationProxy is
now an explicit RotationProxyState container created once at startup
and passed to plain module-level functions; function bodies are
unchanged apart from closure-variable -> state-field references.

Module map:
- lib/runtime/rotation-proxy-state.ts (116 lines): RotationProxyState
  container (status, session-affinity store, thread-goal fallbacks,
  rotation stickiness, active AccountManager) plus the deduped
  recoverStaleRuntimeState reload.
- lib/runtime/rotation-account-selection.ts (257 lines): chooseAccount
  and the shared linear-scan fallback.
- lib/runtime/rotation-token-refresh.ts (141 lines):
  ensureFreshAccessToken, the per-manager refresh-commit dedupe
  WeakMap, and applyMonotonicAuthCooldown.
- lib/runtime/rotation-storage-meta.ts (206 lines): the content-hash
  storage-meta cache (readStorageMetaFromDisk and friends).

lib/runtime-rotation-proxy.ts: 2,099 -> 1,505 lines. Every previously
exported symbol is still exported from lib/runtime-rotation-proxy.ts
via re-exports, so lib/index.ts, scripts/codex.js,
scripts/codex-app-router.js, and all test imports are untouched. The
HTTP plumbing helpers (request parsing/forwarding, writeJson and
friends) deliberately stay in runtime-rotation-proxy.ts: moving them
would relocate the entire module rather than break up the closure
state.

https://claude.ai/code/session_01XNtnkLbBiXZxfQQYLMpucB

Author: claude