…ence_allowed turns

Follow-up to prior commit. The initial fix only gated the empty/
thinking-only retry branches, but two other paths still leaked
messages into non-addressed group channels:

1. _status_callback_sync — posts _emit_status() warnings directly to
   the channel (e.g. 'Max retries (3) for invalid responses — trying
   fallback...', 'Empty/malformed response — switching to fallback...',
   compression notices, rate-limit warnings). Now no-ops when
   silence_allowed is True; warnings continue to log internally.

2. The failed-agent error surface — when the agent returns failed=True
   with final_response=None, the gateway was wrapping 'error' into a
   user-facing 'The request failed: ...' message. Now returns an empty
   response in silence_allowed turns, matching the silence contract.

Together with the prior commit, these close off every path by which a
non-@mention group message could produce a visible reply.

Refs NousResearch#13248

…-kaito)

Two leak paths converted raw provider HTTP response bodies into chat
messages that bypassed the silence_allowed guard in group chats.

1. run.py ~L8942: final_response = "⚠️ {result[error]}" on agent failure
   flowed through the normal send path. Now return empty final_response
   and propagate via error field.

2. run.py ~L4004: user-facing fallback leaked 300 chars of raw error.
   New _sanitize_agent_error() extracts HTTP status + message only,
   strips URLs and request_ids, hard-caps at 160 chars.

Real-world symptom: Anthropic out-of-usage HTTP 400 dumped JSON payload
plus request_ids into a group chat with a business contact. Silence
contract was honored for status telemetry but not for the failure-path
final_response.

8-case sanitizer test: all outputs <=160 chars, no req_ids, no URLs.
Gateway test suite regressions: 0 (106 failed, was 107).

Mirrors the cron scheduler's SILENT_MARKER handling so messaging surfaces
(Slack, WhatsApp, Telegram, Signal, Discord) honor the same silence contract.

When the model emits the literal '[SILENT]' token as its entire response
on a non-@mention group message, the gateway now suppresses outbound
delivery entirely instead of posting the token verbatim.

Pairs with cd5956df (silence_allowed flag) and 3fc721cf (status-telemetry
suppression) to form the complete silence-contract fix.

Refs NousResearch#13248.

The Slack adapter sets silence_allowed=(not is_dm) and (not is_mentioned) on
the constructed MessageEvent, but the WhatsApp adapter's _build_message_event
didn't — so even after this PR's plumbing, non-@mention WhatsApp group messages
still ran the empty/thinking-only retry loop and surfaced (empty) warnings,
sanitized errors, or the literal [SILENT] sentinel. Mirror the Slack logic on
WhatsApp using its existing addressed-detection helpers (slash command,
reply-to-bot, @mention, name-pattern match).

Validated end-to-end on a live install: a non-@mention message in a
multi-person WhatsApp group now produces no visible response, while DMs and
direct @mentions retain full retry semantics.

Refs NousResearch#13248

The streaming consumer creates a placeholder via adapter.send() and edits it
during generation via adapter.edit_message(). Both paths bypass the post-agent
[SILENT] suppression in gateway/platforms/base.py, so any draft text — and
notably the literal "[SILENT]" sentinel when it's the model's final output —
leaks into the channel before suppression runs.

Real-world symptom on WhatsApp (with display.streaming: true): a non-@mention
group message produced visible mid-deliberation drafts as message edits, with
the final "[SILENT]" token landing as plain text in the chat.

Gating both _want_stream_deltas and _want_interim_messages on `not
silence_allowed` ensures the post-agent dispatch is the single delivery path
in silence-valid turns, where base.py's [SILENT] handler can suppress cleanly.
DMs and @mentions stream as before.

Refs NousResearch#13248