fix: reconnect Discord gateway on silent WS disconnect

[chaodu-agent]

Summary

Fixes #790 — Discord gateway silently dies after WS disconnect with no reconnect.

Problem

When serenity's client.start() returns Ok(()) (internal reconnect exhausted), the Discord adapter permanently stops receiving events while the container remains "healthy".

Changes

Wraps the Discord client lifecycle in a reconnect loop with exponential backoff:

• Retry on disconnect: client.start() returning Ok(()) or transient errors triggers a reconnect attempt
• Exponential backoff: 1s → 2s → 4s → ... → 60s max on consecutive errors; resets to 1s after a successful session
• Fatal errors exit immediately: DisallowedGatewayIntents and InvalidAuthentication still call process::exit(1)
• Graceful shutdown: loop breaks on shutdown_rx signal (SIGINT/SIGTERM)
• Observability: WARN-level logs on every reconnect attempt with delay info

How it works

loop {
    build handler + client
    client.start().await
    if shutdown → break
    if fatal error → exit
    if transient error → backoff, retry
    if Ok (clean disconnect) → reset backoff, retry immediately (1s)
}

Handler is rebuilt each iteration — all shared state (router, dispatcher) is Arc-wrapped so cloning is cheap. Thread-local caches (participated_threads, multibot_threads) are fresh per reconnect, which is correct since Discord will re-dispatch the READY event.

Testing

• No Rust toolchain available in this environment; verified code structure and borrow semantics manually
• Recommend CI build + integration test with simulated WS drop

Not included (future work)

• Healthcheck endpoint checking WS gateway state (separate PR)
• INFO-level heartbeat logging

https://discord.com/channels/1491295327620169908/1491365157010542652/1503355477612957696

[chaodu-agent]

LGTM ✅ — Solid reconnect loop with correct backoff semantics and clean shutdown handling.

What This PR Does

When serenity's client.start() returns Ok(()) (internal reconnect exhausted) or a transient error, the Discord adapter now automatically reconnects instead of silently dying while the container stays "healthy".

How It Works

Wraps the Discord client lifecycle in a loop with exponential backoff (1s → 2s → 4s → … → 60s max). Fatal errors (DisallowedGatewayIntents, InvalidAuthentication) still exit immediately. Clean disconnects reset backoff to 1s. Shutdown signal (shutdown_rx) is checked at every sleep point via tokio::select! for graceful termination. Handler is rebuilt each iteration — shared state is Arc-wrapped so cloning is cheap.

Findings

#	Severity	Finding	Location
1	🟢	Unified shutdown signal via watch channel — cleaner than per-adapter signal spawns	src/main.rs:363-368
2	🟢	shutdown_task.abort() prevents listener accumulation across loop iterations	src/main.rs:468
3	🟢	Correct backoff semantics: errors escalate, clean disconnects reset	src/main.rs:490-510
4	🟢	Fatal error detection preserved — no retry on auth/intent failures	src/main.rs:475-488

Baseline Check

• PR opened: 2026-05-11
• Main already has: client.start() with fatal error handling, but Ok(()) falls through to shutdown — no reconnect
• Net-new value: Reconnect loop with exponential backoff, proper shutdown integration, handler rebuild per iteration

What's Good (🟢)

• Clean separation of fatal vs transient errors
• Shutdown signal respected at every sleep point — no zombie loops
• Backoff reset on successful session prevents unnecessary delays after transient network blips
• CI green: cargo check + cargo test + 7 smoke tests all pass