fix(sse): guard reasoning-cache write by the same predicate its readers use

[maxmad64bis]

Summary

cacheReasoningFromAssistantMessage() writes to the reasoning-replay cache on every
non-streaming and streaming response that carries reasoning_content, no matter the
provider. Both read paths that ever consume this cache are already narrower than that —
one is gated by requiresReasoningReplay(), the other by a thinkingEnabled request
flag on a specific non-Anthropic Claude-shape branch. So on an install whose traffic
never touches a replay provider, every reasoning-bearing response pays for a cache write,
an index update, and a catch {} for data that will never be read back. TTL keeps it
bounded, but it's still wasted work.

Wrapped both write sites in if (requiresReasoningReplay({ provider, model })). It's not
a perfect match for what the reads actually need — see the caveat below — but it's a
safe superset, and it stops the obviously wasteful case.

Related Issues

Builds on the reasoning-replay cache (#1628). No new issue filed.

Validation

• Change type: other (write-path guard, no change for providers that already use replay)
• Focused tests: tests/unit/chatCore-reasoning-cache-guard.test.ts,
  tests/unit/chatcore-reasoning-cache-write-guard.test.ts
• npm run lint
• New tests included in this PR

Tests Added Or Updated

• tests/unit/chatCore-reasoning-cache-guard.test.ts — checks requiresReasoningReplay()
  directly: it says yes for the provider families the two read sites actually serve
  (deepseek, kimi-coding, xiaomi-mimo explicitly; glm/kimi-k2-style models via the
  pattern fallback), and no for a plain openai/anthropic request. Confirms the guard
  isn't a no-op.
• tests/unit/chatcore-reasoning-cache-write-guard.test.ts — calls the real
  handleChatCore with a mocked upstream and checks the cache through
  lookupReasoning(), for both a replay provider and a non-replay one, streaming and
  non-streaming. This is the part that actually proves the two call sites are wired
  correctly, not just that the predicate itself works.

Coverage Notes

Both write sites (streaming, non-streaming) just get one if around an existing,
already-tested call — no new branches inside the write function itself.

Reviewer Notes

This guard isn't an exact match for what the read side checks — it's close enough in
practice, but worth knowing where it's not: the non-Anthropic Claude-shape read path
(kimi-coding / glm-thinking / zai-style) actually gates on a thinkingEnabled request
flag, and this write guard doesn't look at that flag at all. Every provider/model tested
is covered anyway through requiresReasoningReplay()'s own fallback matching, but that's
not proven exhaustive for every model a given provider might serve — a zai deployment
on a model that doesn't match the kimi-style pattern wouldn't be caught, for example. If
that turns out to matter, the fix is to reconstruct thinkingEnabled at the write site —
skipped here because by the time you're at the write site, chatCore.ts may have already
rewritten the thinking flag
(normalizeClaudeAdaptiveThinking / normalizeClaudeHaikuConstraints), so doing it
properly is its own piece of work, not a one-line fix.

No migration, no feature flag, no new index — this just narrows an existing write.