[Zen] muse-spark-1.3-contributor-free returns literal \n instead of newlines in Responses stream deltas

Description

On 2026-09-07 between ~22:20 UTC and ~02:35 UTC (18:20–22:35 US/Eastern), streaming Responses from muse-spark-1.3-contributor-free via https://opencode.ai/zen/v1/responses delivered response.output_text.delta events whose delta string values contained literal two-character \n (backslash + n) sequences everywhere a line break belonged — zero real newlines in 49 messages across ~4 hours. Same model/endpoint was clean earlier that day and clean again the next day.

Byte signature of affected text: newlines replaced 1:1 by literal \n, everything else intact — double quotes plain (", not \"), non-ASCII (em-dashes) raw. So this is not a client JSON double-decode; the wire JSON must have carried \\n in the delta strings.

Minimal sample (in a code block so rendering can't hide it — the \n below are literal backslash+n characters, not line breaks):

...stays empty like yours.\n\nOn the site, look for which configuration is assigned to this device...

Steps to Reproduce

Observed live (not reliably reproducible — see timing note):

1. POST https://opencode.ai/zen/v1/responses with {"model": "muse-spark-1.3-contributor-free", "stream": true, ...} during the window above.
2. Accumulate response.output_text.delta → delta fields.
3. Joined text contains literal \n instead of newlines.

Expected Behavior

delta values decode to real newlines, as they did before 22:20 UTC and after ~02:35 UTC.

Actual Behavior

delta values contain escaped newlines, as if the SSE serializer re-escaped already-decoded text during the window.

Timing / correlation

• The window coincides with heavy upstream throttling on the free tier: 429 FreeUsageLimitError / rate-limit, 503, and 403 key-limit errors interleaved with the escaped responses.
• One affected response id (from client logs, 2026-09-07T22:20:24Z): resp_6a9f38a71fc0570df4964e41.
• Client-side intake verified byte-exact (plain field access → append → join, no transforms; no decode errors logged), and the identical client build renders clean responses outside the window — pointing at zen's SSE serialization during the degraded period rather than the client.

Environment

• Endpoint: https://opencode.ai/zen/v1/responses, streaming SSE
• Model: muse-spark-1.3-contributor-free
• Client: third-party OpenAI-compatible agent (Hermes), macOS
• Related (same model family on zen, protocol-level, not escaping): #47192, #44847, #44659