What

Redesigns the IChatClient stack so the streaming-vs-non-streaming transport distinction stops leaking into callers, and resilience/observability stop being entangled with transport. The OpenAI Codex 400 {"detail":"Stream must be set to true"} on memory formation was a symptom of this structural debt (the streaming-only conclusion had already been reached twice independently — main loop and SubAgentActor).

Supersedes #1289 and #1309.

Why streaming-everywhere

All 8 providers stream cleanly; non-streaming is the unreliable path — Codex rejects it, and some SDK paths drop reasoning content in it. Standardizing on streaming as the only transport Netclaw issues collapses the provider-capability question entirely (we only wanted capabilities to know who supports non-streaming).

The redesign

Transport — Netclaw issues only streaming requests.

• RetryingChatClient now retries the streaming path, pre-first-chunk (reusing RetryPolicy + the failover iterator pattern). Once a chunk is emitted a failure propagates, so streamed output is never duplicated by a restart. Retry is now a property of the stack, not of the transport a caller happened to pick.
• The five auxiliary callers (title gen, memory distillation, compaction observation, curation, memory extraction) aggregate the stream via the existing StreamingResponseReader (empty-Messages guard + diagnostics) and read response.Text, replacing the non-streaming GetResponseAsync path. This also closes the response.Text vs Messages[^1].Text inconsistency and the empty-stream throw.

Composition — ChatClientBuilder. Per-(provider, model) pipelines are composed via Microsoft.Extensions.AI.ChatClientBuilder (Logging → Retry → VendorOptions → raw) in PipelineChatClientFactory. The .Use ordering is asserted by a test (it flips silently on a bad bump).

Routing — failover is the first policy, not a special case. A router selects which composed pipeline to invoke per call. RoutingChatClient walks an ordered candidate list, so failover = a list of length > 1 and single-provider alerting = the terminal failure of a length-1 walk — this absorbs and deletes FailoverChatClient, AlertingChatClientDecorator, NetclawChatClientProvider, and ResilientChatClientProviderDecorator. The router takes a ChatRoutingContext, so future per-session / per-provider routing slots in as a new policy without a rewrite (built the seam, not the feature). Today's RoleBasedFailoverRouter reproduces the prior wiring.

Logging — stateless + session-correlated. LoggingChatClient is now stateless (the per-session-intended delta/cumulative token counters that sat on a process singleton are gone — real per-session usage already lives in LlmSessionActor). It tags log lines with the ambient session id via SessionLoggingScope, keyed SessionId to match the WithContext("SessionId", …) key actors already use, so one Seq attribute correlates actor and chat-client logs.

Testing

• Full solution build: 0 warnings, 0 errors
• Netclaw.Daemon.Tests: 668/668
• Netclaw.Actors.Tests: 2186/2186
• dotnet slopwatch analyze: clean; file headers present
• New/ported tests: streaming-retry (pre/post-first-chunk, max-retries, cancel), PipelineChatClientFactory order guard, RoutingChatClient failover/unreachable walk, RoleBasedFailoverRouter candidate selection, LoggingChatClient session-scope + stateless usage.

Notes / not in scope

• Per-session/per-provider routing — the seam (ChatRoutingContext) is in; the policy is a future drop-in.
• Mid-stream (post-first-chunk) retry — deliberately not done (would duplicate emitted tokens).
• Adds the Microsoft.Extensions.AI core package (daemon-only) for ChatClientBuilder. Note: it ships its own LoggingChatClient, which collides with Netclaw's in test files importing both namespaces — resolved with a using alias (production uses same-namespace precedence).
• Not run here (need a live model): the Codex end-to-end smoke and the eval suite. Behaviorally the aggregated response text is identical to the prior non-streaming path; only the transport changed.