Codex review: needs real behavior proof before merge.

Summary
Review failed before ClawSweeper could summarize the requested change.

Reproducibility: unclear. The review failed before ClawSweeper could establish a reproduction path.

Real behavior proof
Not applicable: Real behavior proof was not assessed because the Codex review failed.

Next step before merge
Review did not complete, so no work-lane recommendation was made.

Scope change -- pivoting to per-account API queue

Marking as draft while this is overhauled.

Original approach: chain overflow reasoning messages and halve draft stream edit frequency when the Telegram message length limit is hit.

Why that's insufficient: the 1000ms throttle (and any reduction) operates per-dispatch. Ten concurrent sessions on the same bot account each behave individually but collectively can still burst past Telegram's ~30 req/sec account-level limit. Throttling per-message doesn't fix a per-account resource.

New approach: per-account token bucket queue wrapping all mutating Telegram API calls (editMessageText, sendMessage, sendChatAction) for a given bot account:

• ~25 tokens/sec (conservative under the 30/sec global cap)
• On 429, enforce the retry_after delay account-wide -- all concurrent sessions pause together since it's a shared limit
• Streaming edits continue to coalesce before entering the queue (existing throttle handles that), so an active stream contributes ~1-2 queue entries/sec
• Natural backpressure: overflow behaviour (message chaining) becomes a fallback for when a single message hits the 4096 char limit, not a rate-limit workaround

The existing draftLaneEventQueue already serialises correctly within a single dispatch. The gap is that it's not shared across concurrent dispatches on the same account. This change lifts that coordination to the account layer.

Update (May 7): Per-account queue is future work. Current HEAD (6687524823) addresses immediate ClawSweeper findings:

Fixed: adaptive throttle wired into send gate (getAdaptiveThrottleMs()), direct pausedUntil hard block before gate (fixes bypass via fresh chats with lastSentAt: 0), config baseline hashes regenerated.

Remaining: P2 per-account scoping (acknowledged, out of scope for this PR), P2 stale hashes (rebase concern, will regenerate before merge), P3 gate retry timing (low priority). All 35 tests pass.

Combined test branch available: 5.6+claude-cli-telegram-reasoning based on v2026.5.6 with both #71817 and #74508 cherry-picked on top.

If you'd like to try both fixes together:

npm install -g anagnorisis2peripeteia/openclaw#5.6+claude-cli-telegram-reasoning

What's included:

• reasoningDefault config now respected for Telegram/Feishu -- set "reasoningDefault": "stream" in openclaw.json and Claude's extended thinking streams in channel replies without needing /reasoning stream per session
• Reasoning overflow chains to a new message instead of truncating
• Adaptive throttle with account-wide 429 backoff propagation
• QQBot SSRF guard on API endpoints

Feedback welcome -- especially on how the reasoning stream behaves during long thinking blocks and whether the overflow chaining feels natural.

Landed via rebase onto main.

• Scoped tests: pnpm test extensions/telegram/src/draft-stream.test.ts extensions/telegram/src/bot-message-dispatch.test.ts; pnpm check:changed; git diff --check
• Live proof: Telegram draft-stream overflow probe via skill credentials, 4050-char preview plus 1000-char chained continuation, no Telegram over-limit warning
• Changelog: CHANGELOG.md updated
• Land commit: d2ac4ea
• Merge commit: 10bbed8

Thanks @anagnorisis2peripeteia!