fix(server): forward echoed reasoning under reasoning_content too

[inureyes]

Summary

• Investigation on the real checkpoint (jamba-v0.1-4bit, actually AI21-Jamba-Reasoning-3B-4bit): empty content is finish_reason=length only. At max_tokens 64 all three turns stop inside the primed <think> block; at 2048 turns close </think> and fill content. </think> (id 542, not special) is recognized; no budget or marker change is warranted, matching other primed-thinking families.
• The cache miss is a server bug: build_raw_json_messages_with_thinking forwarded an echoed trace only as reasoning, while Qwen3-style and Jamba templates read message.reasoning_content. Jamba keeps its thinking instruction on an earlier user turn only when the following assistant message carries that field, so the turn re-rendered shorter and the history-boundary snapshot never prefixed the next prompt. The trace is now forwarded under both keys. Templates that accept both (Gemma 4, Laguna) read them as alternatives, so nothing renders twice.
• A client that echoes only content still gets the earlier user turn without the instruction. That is the template's rule; it is pinned by a test, noted in the prefix-stability module doc, and documented in docs/supported-models.md.

Test plan

• New server::chat_request::reasoning_content_tests (5 tests: both-key forwarding, Jamba boundary prefixes turn 2 with echoed reasoning, content-only rewrite pinned, no double render, primed-think split and truncation pinned); server::chat_request filter 126 passed
• cargo clippy --release --features cuda --lib --tests -- -D warnings, cargo fmt --check
• Real server on GB10, fresh process, 3 turns echoing reasoning_content at max_tokens 2048: finish stop/stop/stop, content Paris./4/Louvre, cached_tokens 0/41/88 (before: prompt 66 ignored the echo, cached 0 on turns 2 and 3)
• Same server, content-only echo: content non-empty, cached 0/0/0 (documented template behavior)

Closes #2089