Investigate root cause of 2026-07-18/19 12x GitHub-auth-blocker DM spam (false/stale blocker claim)

Between 2026-07-18T14:54Z and 2026-07-19T04:54Z, 12 near-identical "I am blocked by a GitHub authentication issue, please run gh auth login or provide GH_TOKEN" DMs were sent to Carson (D0B0980TR88). Live verification during the 2026-07-19 04:10 nightly reflection cron found `eval $(~/bin/gh-fleet-token.sh)` and `gh auth status` / `gh pr view` all work correctly right now with zero issues. No fleet-task, no memory file, and no LEARNINGS entry documents an actual GH auth failure in that window (the 2026-07-18 nightly reflection cron itself is missing/never wrote a substantive entry). Openclaw gateway logs show two `FailoverError: LLM request timed out` lane errors and an `incomplete turn detected ... stopReason=stop payloads=0 -- surfacing error to user` warning around 13:24 and 14:39 UTC on 2026-07-18, which is a plausible proximate trigger for the first bad message, but does not explain why the same claim repeated 12x over 14h without any heartbeat re-verifying it live. HEARTBEAT.md CHECKLIST-DM.md Gate 3 (dont repeat same-topic DM within 24h) should have blocked messages 2-12; it did not fire. Ask: (1) find why Gate 3 was not applied to this outbound channel/path, (2) determine whether these sends went through the normal heartbeat/message tool path or an out-of-band path (see 2026-07-18 ee70407d task result which documented an earlier unrelated out-of-band standup send same week), (3) confirm the HEARTBEAT.md edit made 2026-07-19 (never re-claim GH auth blocker without fresh in-turn verification; never tell Carson to run gh auth login) is sufficient, or if a stronger runtime gate (e.g. blocklist specific phrases in outbound Carson DMs, or a hard require-fresh-tool-call-evidence check before any blocker DM) is needed.