fix(discord): prevent reply drops when blockStreaming=true

[Sid-Qin]

Summary

• Problem: Discord delivery layer always dropped block payloads, even when blockStreaming=true.
• Why it matters: in block-streaming mode some normal replies were emitted as block payloads and got silently discarded.
• What changed: block payload suppression now applies only when block streaming is disabled, while still suppressing non-error block payloads in normal mode.
• What did NOT change (scope boundary): draft streaming behavior and final-reply formatting remain unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Discord Normal reply delivery silently fails when blockStreaming: true openclaw/openclaw#25921
• Related #

User-visible / Behavior Changes

• Discord channels with blockStreaming: true now receive normal streamed block replies instead of silent drops.

Security Impact (required)

• New permissions/capabilities? (No)
• Secrets/tokens handling changed? (No)
• New/changed network calls? (No)
• Command/tool execution surface changed? (No)
• Data access scope changed? (No)
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Vitest
• Model/provider: N/A
• Integration/channel (if any): Discord monitor
• Relevant config (redacted): channels.discord.blockStreaming=true

Steps

1. Enable channels.discord.blockStreaming=true.
2. Trigger a normal assistant reply in Discord.
3. Verify delivery path for block payloads.

Expected

• Block-streamed replies are delivered.

Actual

• Previously block payloads were suppressed unconditionally and replies could be lost.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: bunx vitest run src/discord/monitor/message-handler.process.test.ts -t "block" passes.
• Edge cases checked: normal mode still suppresses non-error block payloads.
• What you did not verify: live Discord gateway/manual end-to-end run.

Compatibility / Migration

• Backward compatible? (Yes)
• Config/env changes? (No)
• Migration needed? (No)
• If yes, exact upgrade steps:

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this PR commit.
• Files/config to restore: src/discord/monitor/message-handler.process.ts and test file.
• Known bad symptoms reviewers should watch for: duplicate preview/final posts in non-block-streaming mode.

Risks and Mitigations

• Risk: block payload handling could regress into duplicate delivery.
  • Mitigation: tests now cover both suppression mode and blockStreaming-enabled delivery mode.