Per-provider concurrency cap does not cover stream_completion() — only chat_completion() is bounded #16538

Problem

#16527 added a per-provider asyncio.Semaphore admission-control cap in
BaseProvider.chat_completion() (autobot-backend/llm_shared/base_provider.py),
sized from LLMSettings.max_concurrent_requests. It only covers
chat_completion(). stream_completion() is abstract on BaseProvider with
no shared wrapper — each of the 8 provider subclasses
(anthropic.py, vertexai.py, bedrock.py, vllm_base.py, huggingface.py,
ollama_provider.py, mistral.py, openai_compatible.py) implements it
independently, calling its own network client directly. None of them go
through BaseProvider's breaker, rate limiter, backoff handler, or the new
concurrency semaphore.

services/llm_service.py::LLMService.stream() calls
provider.stream_completion(request) directly (never chat_completion()),
so every streaming request bypasses all of that protection, not just the new
cap — this is a pre-existing gap the #16527 audit surfaced as a side effect,
not introduced by it.

Location

• autobot-backend/llm_shared/base_provider.py — chat_completion()'s wrapper
  (breaker, rate limiter, concurrency semaphore) has no streaming counterpart
• autobot-backend/services/llm_service.py::LLMService.stream() — calls
  provider.stream_completion() directly
• 8 provider-specific stream_completion() implementations under
  autobot-backend/llm_shared/providers/

Impact

A burst of streaming requests to one provider has none of: circuit-breaker
fail-fast, cross-worker rate limiting, backoff/retry, or (after #16527)
concurrency admission control. Only non-streaming chat() is protected today.

Acceptance Criteria

• Decide and document the shared choke point for streaming requests (a
  wrapper analogous to chat_completion()'s _attempt(), or a per-call
  semaphore acquired in LLMService.stream() around
  provider.stream_completion())
• The per-provider concurrency cap (LLMSettings.max_concurrent_requests)
  is enforced for streaming requests too
• Test demonstrates a streaming burst past the cap queues rather than
  running unbounded
• No existing streaming test broken

Context

Discovered while implementing #16527 (per-provider concurrency cap). Scoped
out of that PR: retrofitting 8 independent stream_completion()
implementations is a materially larger, separate-risk change from adding one
semaphore to the single chat_completion() call path. Related umbrella: #16524.