BYOK: Add an option to disable streaming (request stream:false from the provider) #3717

Describe the feature or problem you'd like to solve

Add option to disable streaming responses from the LLM provider

Proposed solution

Add a way to make Copilot CLI send stream:false on its requests to a BYOK/custom OpenAI-compatible provider — e.g. an env var COPILOT_PROVIDER_DISABLE_STREAMING=true (and/or a config field).

Example prompts or workflows

Some self-hosted backends have streaming-only bugs that corrupt tool-call arguments. On our vLLM + Gemma deployment, the streaming tool-call parser duplicates characters at chunk boundaries in large tool-call arguments (file contents in write/edit): <html → <<htmlhtml, <h1 → <<hh1. The identical request with stream:false is clean. Minimal repro — same body, only stream differs:

# stream:false → arguments contain a clean document
# stream:true  → reconstructed arguments contain "<<htmlhtml", "<<headhead", ...
curl -s $EP/v1/chat/completions -d '{"model":"...","stream":<bool>,"tools":[{"type":"function","function":{"name":"write_file","parameters":{"type":"object","properties":{"path":{"type":"string"},"content":{"type":"string"}}}}}],"messages":[{"role":"user","content":"Call write_file with index.html and a complete HTML document as content."}]}'

Because the CLI always streams to the provider, every edit comes back corrupted (<<hh1, "No match found" loops), making it unusable against these backends until the upstream fix ships.

Additional context

• Today the only workaround is a local stream-stripping proxy that forces stream:false upstream. A first-class CLI option would remove the need for that.
• Scope can be limited to openai/azure provider types where non-streaming chat/completions is supported.