conversation: scrub OpenClaw tool_code fences before TTS

[tundakk]

Summary

Strip ```tool_code``` markdown fences from conversation responses before they reach the Assist pipeline.

When OpenClaw is paired with a workspace plugin that handles tool calls via gemma3-style fences (e.g., a custom record_fact tool in a personal-memory plugin), Voice PE TTS literally speaks the raw call: "record underscore fact open paren person underscore slug equals quote...". OpenClaw's plugin hook system rewrites the persisted transcript via before_message_write, but result.payloads is built directly from raw LLM output upstream of any hook — verified empirically with stream:false (the response payload still surfaces the raw fence even when persistence-side bridges have logged the rewrite). The architectural fix would belong upstream in openclaw/openclaw (firing before_message_write on result.payloads too, or a new before_response_finalize hook); this PR is a localized HA-side scrub.

The scrubber is 15 lines, no new dependencies, applied symmetrically on both the streaming and non-streaming response paths in _get_response. Behavior:

• Fence-only output (typical for record_fact-style turns) → "OK."
• Mixed response (text before/after fence) → fence stripped, surrounding text preserved
• Normal responses without fences → unchanged

Test plan

• record_fact-triggering prompt round-tripped through /api/services/conversation/process?return_response=true: speech.plain.speech is "OK." (was raw fence)
• Normal query "What is son1 favorite color?" round-trips unchanged: "Son1's favorite color is blue. Source: family_db#son1.favorites.color"
• HA integration loads clean after restart, no new warnings (the existing line-316 SyntaxWarning is unrelated)
• Underlying DB write still fires (the persistence-path bridge is unaffected — verified via gateway journal)

🤖 Generated with Claude Code