fix(mac-chat): actually stop [stream] lines interleaving (the part #152 squash-dropped)

[FluffyAIcode]

Why this is needed (the format problem is still happening after #152)

PR #152 was squash-merged at its first commit only. That first commit added token streaming but wrote the per-block [stream] blk=.. t=..s progress line unconditionally to stderr. The follow-up commit that fixed the format — moving that write into an else: branch so it only fires on the non-interactive path — never reached main (the squash captured the pre-fix state).

So merged main still has the unconditional sys.stderr.write("[stream]…"), which fires even in interactive (to_stdout=True) mode, and on a shared terminal it interleaves into the answer (DIGEST[stream] blk=99 …, sprintf([stream] blk=102 …) — exactly the screenshot the user reported.

Fix

Cherry-picks the missing commit onto current main: the [stream] timing line now lives in the else: (non-interactive) branch of _make_stream_cb, so the interactive CLI streams only the clean answer delta. Also brings the --chat-stream-stdout flag so a non-tty bridge run can capture the exact clean format.

Validation (Mac M4, re-run on this branch)

Stream probe on the user's exact prompt, capturing stdout: 0 [stream] occurrences; the answer streams as clean continuous markdown:
gemma-4 [根据pow的机制…]> 在计算机科学中，实现 \pow(base, exp)` 函数通常有两种主要的机制：快速幂算法（Binary Exponentiation） 和 对数/指数转换法…` (blocks=62, f_theta_ran=True, 5.16 tok/s).

mac_chat_format_fix_completion.txt

Testing

• ✅ pytest tests/inference_engine/bridge/test_manifest.py (31 passed)
• ✅ On-device probe: 0 [stream] interleaving, clean streamed answer
• py_compile clean

Tip for future merges: prefer a normal (non-squash) merge for multi-commit PRs, or re-confirm the squash includes the latest commit, so a later fix commit isn't dropped.

_{To show artifacts inline, enable in settings.}