fix(provider): only send tool_stream for Z.AI providers in streaming path

[zavertiaev]

Summary

• Base branch target: master
• Problem: stream_chat_with_tools unconditionally set tool_stream: true for all providers when streaming was enabled, causing 400 Bad Request on non-Z.AI OpenAI-compatible endpoints (e.g. litellm proxies) that reject the unrecognized tool_stream key.
• Why it matters: Any user with a custom OpenAI-compatible provider (litellm, vLLM, etc.) cannot use streaming tool calls — every request fails with 400.
• What changed: Streaming payload now uses self.tool_stream_for_tools() (same guard as non-streaming path) so tool_stream is only serialized for Z.AI providers.
• What did not change (scope boundary): Non-streaming paths, Z.AI provider behavior, request structure for any other fields.

Label Snapshot (required)

• Risk label: sk: low
• Size label: size: XS
• Scope labels: provider
• Module labels: provider: compatible
• Contributor tier label: (auto-managed)
• If any auto-label is incorrect: N/A

Change Metadata

• Change type: bug
• Primary scope: provider

Linked Issue

• Related [Bug]: #2901

Supersede Attribution (required when Supersedes is used)

N/A

Validation Evidence (required)

Commands and result summary:
```bash
cargo fmt --all -- --check # exit 0, no output
cargo clippy --all-targets -- -D warnings # exit 0, Finished dev profile
cargo test -p zeroclaw-providers # 762 passed; 0 failed; 0 ignored
```

• Evidence provided: local test run output
• If any command is intentionally skipped: N/A

Security Impact (required)

• New permissions/capabilities? No
• New external network calls? No
• Secrets/tokens handling changed? No
• File system access scope changed? No

Privacy and Data Hygiene (required)

• Data-hygiene status: pass
• Redaction/anonymization notes: N/A
• Neutral wording confirmation: Yes

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

i18n Follow-Through (required when docs or user-facing wording changes)

• i18n follow-through triggered? No

Human Verification (required)

• Verified scenarios: Custom OpenAI-compatible provider (litellm proxy) previously returned 400 due to tool_stream key — confirmed root cause via docker logs.
• Edge cases checked: Z.AI providers still get tool_stream: true (existing tests pass). Non-Z.AI providers with/without tools get None.
• What was not verified: Live streaming with Z.AI provider (no access).

Side Effects / Blast Radius (required)

• Affected subsystems: OpenAiCompatibleProvider::stream_chat_with_tools only
• Potential unintended effects: None — Z.AI behavior preserved via existing requires_tool_stream() gate
• Guardrails: Existing test suite (762 tests), plus new non_zai_provider_omits_tool_stream_regardless_of_streaming test

Agent Collaboration Notes (recommended)

• Agent s used: Cursor AI
• Workflow: Docker log analysis → root cause in streaming path → fix + test
• Confirmation: naming + architecture boundaries followed (AGENTS.md)

Rollback Plan (required)

• Fast rollback command: git revert <commit>
• Feature flags or config toggles: None
• Observable failure symptoms: 400 errors from non-Z.AI OpenAI-compatible proxies with Unrecognized key(s) in object: 'tool_stream'

Risks and Mitigations

• Risk: Z.AI streaming could regress if requires_tool_stream() has a bug
  • Mitigation: Existing zai_tool_requests_enable_tool_stream and z_ai_host_enables_tool_stream_for_custom_profiles tests cover this

[JordanTheJet]

Verdict: Needs author action (minor)

Thanks @zavertiaev — small, surgical fix that closes a real bug for non-Z.AI OpenAI-compatible proxies (litellm, vLLM, etc.). Nice work.

Comprehension summary

• What: In OpenAiCompatibleProvider::stream_chat_with_tools, the streaming request builder unconditionally set tool_stream: Some(true) whenever streaming was enabled. This PR routes both branches (tools and no-tools) through the existing self.tool_stream_for_tools(has_tools) helper, so tool_stream is only emitted for Z.AI-hosted providers (host api.z.ai / *.z.ai or provider name zai/z.ai), matching the non-streaming path.
• Why: tool_stream is a Z.AI-specific request field. Non-Z.AI OpenAI-compatible endpoints (litellm proxies, vLLM, etc.) reject the unknown key with 400 Bad Request, breaking streaming tool calls for those users entirely.
• Blast radius: Scoped to crates/zeroclaw-providers/src/compatible.rs streaming path. Z.AI providers retain the exact same behavior via requires_tool_stream() (unchanged). Non-Z.AI providers stop emitting a field they never should have emitted.

What I verified

• Read the diff and confirmed both streaming branches now go through tool_stream_for_tools(...), aligning with the non-streaming paths at lines 1964 and 2062–2063 that already use the same helper.
• Confirmed requires_tool_stream() at line 429 correctly gates on host (api.z.ai / *.z.ai) and provider name (zai/z.ai) — the Z.AI detection is robust and unchanged.
• tool_stream_for_tools(false) returns None unconditionally (short-circuits on !has_tools), so the no-tools branch now never emits the field regardless of provider — desirable since tool_stream has no meaning without tools.
• Only this one file in the repo references tool_stream — no downstream callers to regress.

Validation battery

• cargo fmt --all -- --check — pass
• cargo clippy --all-targets -- -D warnings — pass, zero warnings
• cargo build — pass, zero warnings
• cargo test --workspace — PR-relevant tests pass:
  • non_zai_provider_omits_tool_stream_regardless_of_streaming (new) — pass
  • non_zai_tool_requests_omit_tool_stream — pass
  • z_ai_host_enables_tool_stream_for_custom_profiles — pass
  • zai_tool_requests_enable_tool_stream — pass
• Pre-existing test failures observed, NOT caused by this PR: Four flatten_system_messages_* tests in zeroclaw-providers fail on both master (origin/master at 9ca90b1b) and this branch. Root cause: tests call flatten_system_messages(&input, false) but expect merge behavior; the function's first line if !merge { return messages.to_vec(); } returns early. Introduced in commit d6dca4b8 (unrelated contributor). CI green because cargo nextest run --locked as invoked in .github/workflows/ci-run.yml apparently does not pick up these workspace-crate lib tests. Flagging as a separate CI-gap / test-calibration issue for maintainers — out of scope for this PR.

Security / performance assessment

• Security: No impact. Removing a provider-specific payload key from providers that reject it does not expand attack surface or weaken deny-by-default. No auth, secrets, or validation paths touched.
• Performance: No impact. One method call per request instead of a literal; allocation profile unchanged.

Architectural notes

• Aligns streaming path with non-streaming paths (lines 1964, 2062–2063) that already use tool_stream_for_tools(...). Reduces divergence, not adds it.
• No new dependencies, no binary-size impact, no runtime deps.

Findings

1. [suggestion] Label snapshot typo / missing labels. The PR body lists Risk label: sk: low (should be risk: low) and Size label: size: XS, but the PR has zero labels applied on GitHub. This appears to be auto-labeling drift rather than a deliberate choice. Could you either apply risk: low, size: XS, provider, provider: compatible manually, or leave a note confirming auto-label will fire on next push?

What must change before re-review

• Address the label suggestion above (or confirm it's intentional/auto-managed).

Once the labels land this is ready for maintainer merge. The code change itself is correct, minimal, well-tested, and aligned with the existing pattern.

[singlerider]

Code is correct and well-tested. Approving.

[singlerider]

This will be merged after v0.7.0 is cut.