fix(provider): treat missing/null finish_reason as stop instead of other

[anandlo]

Summary

Some gateways served by the OpenCode Go gateway (opencode.ai/zen/go/v1) do not emit a finish_reason in streaming responses (and return null in non-streaming). The mapping then fell through to default: return "other", which made classify.ts flag every such response as degraded / think-only even though the response was delivered normally.

Affected model: muse-spark-1.2-contributor.

Evidence (live gateway streaming captures)

Model	Streaming finish_reason
deepseek-v4-pro	['stop'] ✓
glm-5	['stop'] ✓
muse-spark-1.2-contributor	(none sent) ✗

Changes

• map-openai-compatible-finish-reason.ts: add a null/undefined guard before the switch that returns "stop".
• openai-compatible-chat-language-model.ts: change the streaming initial finishReason.unified default from "other" to "stop" (models that send a proper finish_reason still override it).
• Added test/provider/map-openai-compatible-finish-reason.test.ts covering null/undefined plus regression cases (stop, length, tool_calls, other, content_filter, "").

Verification

• bun typecheck from packages/opencode/ passes.
• bun test test/provider passes: 482 pass / 0 fail (8 new tests included).

Fixes #2173

Test plan

• Stream muse-spark-1.2-contributor and confirm finish is reported as stop, not other.
• Confirm deepseek-v4-pro / glm-5 still report stop as before (no regression).

[EsanRAHIMI]

The missing-finish-reason fallback should account for tool calls before defaulting to stop. This gateway is described as omitting finish_reason entirely, so a streamed response containing delta.tool_calls will also keep the new initial unified: "stop" value. The transform still emits the tool calls in flush(), but the final finish part now says the model stopped normally rather than tool-calls; consumers that use the finish reason to decide whether to continue the agent/tool loop can terminate early. Could flush() set the fallback to tool-calls when toolCalls.length > 0 (and no explicit reason was received), with a streaming regression test for a tool-call response that omits finish_reason?