Solid implementation. A few observations:

Correctness — The _last_assistant_rationale closure captures the most recent non-empty text from _interim_assistant_cb, which is the right signal. One subtle case: if the agent emits a large streaming blob and the rationale is the first segment rather than the last, only the most recent chunk is preserved. In practice this is usually fine (the final reasoning summary is typically at the end), but worth a comment.

QQBot path — The QQBot adapter sends the rationale as a separate preceding message (await self.send(...)) rather than embedding it in the approval card. This is pragmatically correct (QQBot's card format is more rigid), but it creates a minor race: if the approval card arrives before the rationale message on slow connections. The await before the approval request preserves send order — looks correct.

Telegram HTML escape — Confirm contextual_reason gets HTML-escaped before injection into Telegram's parse_mode=HTML render path to avoid accidental tag injection from streaming text that contains <, >, or &.

Tests — 8 tests covering all 7 adapters is good coverage. One useful edge-case to add: rationale containing Markdown/HTML special characters (backticks, <, >) to exercise escaping paths.

Overall this is a clean, useful feature — good work.

Thanks for the thorough review, @Bartok9!

Streaming rationale ordering: Good catch — the closure captures the most recent non-empty chunk, which is indeed the final reasoning summary in the common case. I'll add a docstring comment clarifying this behavior for future maintainers.

QQBot race condition: You're right that the separate send() for the rationale could theoretically arrive after the approval card on slow connections. In practice QQBot's WebSocket channel serializes within a session, but the defensive fix (embedding rationale in the card when possible) is cleaner long-term. I'll note this as a follow-up improvement.

Both points are non-blocking observations — appreciate the detailed analysis!