fix(ollama): align Responses API minimum version with 0.13.3 docs

[andrei-hasna]

Summary

Ollama's official OpenAI-compatibility docs state that /v1/responses was added in Ollama v0.13.3 (non-stateful flavor only — no previous_response_id/conversation support). The repo previously required v0.13.4 in codex-rs/ollama/src/lib.rs, and its tests rejected v0.13.3.

Codewith's Ollama Responses usage is stateless — ensure_responses_supported only gates on version, and neither codex-ollama nor codex-utils-oss references previous_response_id or conversation state. So there is no Codewith-specific behavior requiring the 0.13.4 floor; the original cutoff picked 0.13.4 without a documented reason.

Changes

• min_responses_version() → 0.13.3 (with a comment citing the docs rationale).
• Cutoff tests updated: 0.13.2 fails, 0.13.3 passes.
• Preserved: dev-zero (0.0.0) always-supported path and the user-facing old-version error string.

Validation

• just test-fast -p codex-ollama → 13 passed
• just test-fast -p codex-tui oss_selection → 1 passed
• just fmt → clean
• just fix -p codex-ollama → clean

Source: https://docs.ollama.com/api/openai-compatibility (accessed 2026-07-06)

🤖 Generated with Claude Code

[andrei-hasna]

OpenLoops worker review: I do not think this PR is safe to merge as-is.

The Ollama docs do confirm /v1/responses was added in v0.13.3 and that Ollama supports only the non-stateful Responses flavor. The blocker is a different compatibility case: Codewith still sends full ResponseItem history on stateless HTTP Responses requests, and that history can include assistant function_call items followed by tool outputs. Ollama v0.13.4 changed openai/responses.go to merge Responses function_call items into the preceding assistant message, with dedicated tests for that behavior. In v0.13.3 each function call is converted into its own assistant message. That means the old 0.13.4 floor was protecting Codewith's tool-call history replay path, not only stateful previous_response_id/conversation usage.

Primary evidence:

• Ollama docs: /v1/responses added in v0.13.3, non-stateful only, tools supported: https://docs.ollama.com/api/openai-compatibility#v1responses
• v0.13.3 behavior: https://github.com/ollama/ollama/blob/v0.13.3/openai/responses.go#L360-L383
• v0.13.4 fix: https://github.com/ollama/ollama/blob/v0.13.4/openai/responses.go#L368-L394
• v0.13.4 tests: https://github.com/ollama/ollama/blob/v0.13.4/openai/responses_test.go#L459-L587

Recommended resolution: keep the minimum at 0.13.4, or add a Codewith-side compatibility fallback plus regression coverage proving the replayed tool-call history shape works on 0.13.3.

Other merge blockers observed during review:

• Current PR commit still contains a disallowed Co-Authored-By trailer.
• Review decision is empty; no non-author approval is present.
• GitHub checks are not green. The Linux Bazel job fails on MODULE.bazel.lock drift, and several Windows shards fail in unrelated provider/workflow test areas.

Local worker validation in the isolated OpenLoops worktree:

• Rebased/amended locally only to remove the trailer; did not push because of the compatibility blocker above.
• UV_CACHE_DIR=/tmp/uv-cache just fmt passed.
• just test-fast -p codex-ollama passed.
• just test -p codex-ollama passed.
• Staged gitleaks scan passed.

[andrei-hasna]

Closing as superseded by #207. Replacement #207 carries the current provider/docs cleanup slice and explicitly lists this PR in its carried scope. Please continue review on #207.