fix(buzz): reply in-thread instead of flat channel posts

[nanakoice]

Summary

Buzz channel threading depends on buzz messages send --reply-to <event-id>. Hermes was dropping the reply anchor for most mid-turn and progress sends, so agents (e.g. Kathy) flooded channels with top-level posts instead of nesting under the triggering message.

Changes

1. plugins/platforms/buzz/adapter.py — honor metadata.reply_to_message_id (gateway stream/progress path), not only thread_id.
2. gateway/stream_consumer.py — pass reply_to=self._initial_reply_to_id on interim commentary sends.
3. gateway/run.py — treat buzz like slack/mattermost for progress thread resolution; set _progress_reply_to to the trigger event id for buzz.

Tests

• test_send_uses_metadata_reply_to_message_id (buzz adapter)
• test_buzz_uses_event_message_id_as_progress_thread (progress routing)

Config note (optional hygiene)

For Buzz, official docs still recommend:

display:
  platforms:
    buzz:
      interim_assistant_messages: false
      tool_progress: "off"

This PR fixes threading even if those remain on; suppressing interim traffic further reduces noise.

Motivation

Live deploy: one agent produced ~65 channel posts with only ~8 threaded. After these fixes + display hygiene, new replies nest under the user message.

[alt-glitch]

This was generated by AI during triage.

Related to #77080 and #80651: all address Buzz progress replies escaping the triggering thread, but this patch combines gateway reply-anchor propagation with adapter metadata handling. Maintainers should choose or consolidate the overlapping approaches.

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(buzz): reply in-thread instead of flat channel posts

1. gateway/stream_consumer.py::_send_commentary now passes reply_to=self._initial_reply_to_id and metadata=self._metadata_for_send(final=False) for all platforms, not just Buzz. If _initial_reply_to_id is ever non-None on a platform that previously posted commentary flat (e.g. a platform where the trigger id is not a valid reply target), this silently changes its threading behavior. Either gate the reply anchor by platform or verify _initial_reply_to_id stays None on the others — the Buzz adapter change alone would have been the narrower fix.
2. gateway/run.py detects Buzz via str(getattr(source.platform, "value", source.platform) or "").lower() == "buzz" — a magic-string compare duplicated with the adapter logic. A small is_buzz helper or platform-constant set would keep this consistent as the platform list grows.
3. Adapter precedence reply_to or meta.get("thread_id") or meta.get("reply_to_message_id") is fine for Buzz today, but if a sender ever passes both thread_id and reply_to_message_id, thread_id silently wins even though Buzz has no native threads. Consider preferring reply_to_message_id when thread_id is falsy, or asserting the two never collide.
4. Test coverage for _resolve_progress_thread_id and the adapter metadata path is good; the _generic_status_phrase Buzz branch has no direct unit test (the resolver tests cover the thread-id derivation, so this is minor).