Discord adapter wedges in start-account and self-starves event loop

Repro: any cold boot of gateway with channels.discord.enabled=true on a machine where there's competing startup work (subagent recovery, session locks, embedded run prep). Wedge is deterministic on my box — happens on every restart, regardless of waiting time.

Symptoms (from openclaw-2026-05-09.log)

• Gateway reports gateway ready but stays in phase=channels.discord.start-account indefinitely (observed 9h+ in one case, 32,806,272 ms phase duration).
• Repeated:

  fetch-timeout: timeoutMs=10000, elapsedMs=13282, url=https://discord.com/api/v10/users/@me
  "fetch timeout reached; aborting operation"

• liveness warning: eventLoopDelayMaxMs=14621 eventLoopUtilization=0.81 phase=channels.discord.start-account
• Cron jobs and replies pile up failing because main agent loop is starved.
• "Auto-restart circuit OPEN -- 3 restarts in last 24h failed to fix Discord."
• Disabling channels.discord.enabled=false is hot-reloadable and immediately recovers the event loop. Re-enabling deterministically reproduces the wedge.

Verified NOT the cause

• DNS / network: Resolve-DnsName discord.com and GET https://discord.com/api/v10/gateway both 200 from the host while wedge is active.
• Token: probe occasionally completes and returns the correct bot user; rotated and re-verified within last 48h.
• User activity: wedge persists hours after the last user message; "wait quietly then send one message" doesn't help.

Likely root cause

/users/@me cold-boot probe in channels.${id}.start-account:

• 10s fetchWithTimeout is too aggressive for a cold Node process where bundle/init work and other startup phases are still landing on the main thread.
• On timeout the adapter appears to retry tightly with no exponential backoff, queueing more work onto an already-loaded loop, which makes the next fetch more likely to time out → self-starvation.
• The "auto-restart circuit breaker" correctly stops parent restart loops, but does not pause the inner retry loop, so the gateway stays warm but useless.

Suggested fixes

1. Exponential backoff on /users/@me failures (e.g. 1s → 60s cap, jitter).
2. Bump cold-boot fetch timeout (/users/@me) to ~30s; this is a one-shot identity check, not a hot path.
3. Circuit breaker should pause inner retry, not only parent restart, when N consecutive fetch-timeouts land in start-account. Surface a clear lastError in the channel runtime status.
4. (nice-to-have) Defer start-account work behind a small idle-priority queue / setImmediate ladder so it yields to other startup phases instead of fighting them on the same tick.

Environment

• OpenClaw v2026.5.7, embedded mode, loopback gateway on 127.0.0.1:18789.
• Windows 11 (Windows_NT 10.0.26200 x64), Node v24.14.1.
• @openclaw/discord channel enabled, single bot account, ~15 channel bindings across one guild.
• Host is otherwise idle; CPU and bandwidth not constrained.

Workaround currently in use

channels.discord.enabled = false in ~/.openclaw/openclaw.json, hot-reloads cleanly, restores normal operation.