[Bug]: Runtime-command replies enter conversational voice routing

Affected component

channel

Severity

S2 - degraded behavior

Current behavior

In crates/zeroclaw-channels/src/orchestrator/mod.rs, stop_reply_message constructs /stop acknowledgments with SendMessage::reply_to without setting suppress_voice. The common send at the end of handle_runtime_command_for_delivery does the same for operational responses, including /thinking, /model, /new, configuration output, and invalid-command arguments handled there.

Telegram's sender queues automatic voice replies when this flag is false. For voice-only peers, it can also return before sending text. Operational feedback therefore enters conversational TTS routing; content heuristics and synthesis determine whether an audible response is produced.

This source-established follow-up from #10827 has not been reproduced through a live Telegram session. It is separate from #10922: that issue concerns WhatsApp ignoring a flag that is already set; this issue concerns runtime producers not setting it.

Expected behavior

Mark /stop acknowledgments and the common runtime-command responses as text-only with suppress_voice. Preserve reply routing, thread metadata, command execution, cancellation behavior, and native model-picker interactions. Ordinary assistant responses should retain their existing voice behavior.

Steps to reproduce

Proposed controlled regression, not yet executed:
1. Capture the outgoing SendMessage for both /stop outcomes: active work cancelled and no active work.
2. Capture responses for /thinking, a model-selection confirmation, and /new through the runtime-command handler.
3. Assert suppress_voice is true and existing recipient/thread metadata is unchanged.
4. Exercise the Telegram sender with a voice-only peer and a suppressed operational reply: assert text delivery and no automatic TTS queue entry.
5. Keep an ordinary unsuppressed assistant reply as the voice-routing positive control.

Impact

Operational confirmations can be voiced instead of remaining immediately readable. For voice-only Telegram peers, text is skipped even though content heuristics or TTS availability can prevent a voice reply. Live failure frequency has not been measured.

Logs / stack traces

No response

ZeroClaw version

3df68fb2236c6f089c25005d0ebb780c9c7fd642

Rust version

Not measured; source-based report.

Operating system

Not platform-specific in the inspected code; no live platform reproduction performed.

Regression?

Unknown

Pre-flight checks

• I reproduced this on the latest master branch or latest release.
• I redacted secrets, tokens, and personal data from all submitted content.