muse-spark-1.2-contributor-free: stream always ends without finish_reason — every request fails in strict OpenAI-compatible clients

Summary

Every streaming request to muse-spark-1.2-contributor-free on the OpenCode Zen gateway completes the visible output successfully but never delivers a terminal choices[0].finish_reason chunk, so strict OpenAI-compatible clients treat every turn as an aborted/incomplete stream. With my client (oh-my-pi's openai-completions provider) every single request ends in:

OpenAI completions stream closed before a finish_reason was received

This is deterministic — it happens on every request, not intermittently.

This looks like the same underlying defect already reported in #43379 for muse-spark-1.2-contributor / legacy alias muse-spark-1.2; this report adds that the free-tier variant (muse-spark-1.2-contributor-free) is affected as well.

Environment

• Model: muse-spark-1.2-contributor-free
• Endpoint: OpenCode Zen gateway, OpenAI-compatible chat/completions, "stream": true
• Client: oh-my-pi, packages/ai/src/providers/openai-completions.ts — its stream parser requires a final chunk with non-null finish_reason; when the stream closes without one after delivering content it throws ProviderResponseError("OpenAI completions stream closed before a finish_reason was received")

Steps to reproduce

1. Send any streaming chat completion request for muse-spark-1.2-contributor-free through the OpenAI-compatible Zen endpoint.
2. Observe that the full assistant reply streams normally.
3. Inspect the raw SSE tail after the last content delta.

Expected behavior

Per the OpenAI streaming contract (detailed in #43379), the stream must end with a chunk whose choices[0].finish_reason is non-null ("stop", "tool_calls", ...), followed by data: [DONE].

Actual behavior

• All content deltas arrive and the reply reads as complete.
• No chunk with a non-null finish_reason is ever sent; the stream simply closes.
• Validating clients therefore raise an end-of-stream error even though generation succeeded, which makes the model unusable from strict OpenAI-compatible clients.

Suggested fix

Same direction as proposed in #43379: ensure muse-family streams terminate with the standard {"choices":[{"index":0,"delta":{},"finish_reason":"stop"}]} chunk plus data: [DONE] — e.g. synthesize a finish reason from the transport when the upstream doesn't provide one. Fixing it at the gateway level would cover all muse variants (contributor, contributor-free, and others) at once.

Happy to capture a raw SSE transcript of a failing request if that helps.