[Improve] Harden the Discord gateway delivery and leadership paths

[daniel-lxs]

Reliability follow-ups to #268, from the gateway review that ran before it merged.

Changes

• Dead-letter visibility — quarantined (undeliverable) events now surface: the gateway status tracks deadLetterDepth and Discord settings shows a failing Event delivery diagnostic row when anything is quarantined, instead of events accumulating in a stream nothing reads.
• Bounded streams — the durable inbound stream and the dead-letter stream get approximate MAXLEN caps (DISCORD_GATEWAY_INBOUND_MAX_ENTRIES, default 50k; DISCORD_GATEWAY_DEAD_LETTER_MAX_ENTRIES, default 1k). A multi-hour delivery outage can no longer grow Redis without limit; capacity pressure is reported in status before shedding starts.
• Lease-renewal tolerance — a single transient Redis error on the 10s renew no longer tears down a healthy Gateway connection whose 30s lease is still valid. renewDetailed on the Redis lock distinguishes definitive ownership loss (immediate teardown) from a transient error (tolerated once).
• Backoff reset — the delivery-loop restart backoff starts over after a long healthy run instead of ratcheting toward the 30s maximum for the lifetime of the process.
• Supervisor death pages — the embedded supervisor takes an onFatal hook (wired to Sentry in the BullMQ host) and stamps the shared status, so silently-stopped Discord ingestion is visible in error tracking and diagnostics rather than only a console line.

Validation

• discord-gateway suite: 72/72 (includes new coverage: stream bounds + DLQ depth, backoff reset via fake-timer choreography, onFatal + status stamping)
• web DiscordSetupStatus and bullmq suites green; check-types 26/26, oxlint, format, knip all pass
• Honest gap: the lease-renewal streak logic in service.ts has no direct unit harness (the renew timer isn't injectable); it's covered by the renewDetailed contract and kept deliberately simple.

🤖 Generated with Claude Code

[roomote-roomote]

No new code issues found. See task

• Bound retry metadata when stream entries are shed — apps/discord-gateway/src/inbound-queue.ts:16: MAXLEN can evict undelivered entries without deleting their fields from DISCORD_INBOUND_ATTEMPTS_KEY; during a sustained outage, each newly exposed oldest entry is attempted and later trimmed, so the attempts hash still grows without bound. Remove stale attempt fields as entries are shed or store retry metadata in a structure that is bounded with the stream.
• Keep capacity pressure visible while the backlog remains high — apps/discord-gateway/src/service.ts:176-190 and apps/discord-gateway/src/delivery-loop.ts:99-103: the timer writes the pressure warning to lastError, but every successful delivery immediately publishes lastError: undefined. With partial throughput and a queue still above 90%, the warning is repeatedly erased even as MAXLEN is about to shed events; use a dedicated pressure field or only clear the warning after depth falls below the threshold.
• Avoid deleting live retry counters during empty-stream pruning — apps/discord-gateway/src/inbound-queue.ts:212-228: XRANGE and HKEYS/HDEL are separate operations. If XRANGE observes an empty stream, then an event is enqueued and delivery records its attempt before HKEYS, oldestId === null causes that live counter to be deleted, resetting retry accounting and allowing more than the configured maximum attempts. Snapshot the tracked IDs before reading the oldest entry or make the cleanup atomic, and cover that ordering in a test.

_{Reviewed fd390b3}