server: don't stop generation inside a thinking block (and warn when it happens)

[alangiu-gif]

The failure mode

When generation stops in the middle of a thinking block, the truncated reply is the
visible half of the problem. The invisible half is that it poisons the session KV cache.

If the block never closes, thinking_live never becomes valid, so
kv_cache_store_current() falls back to keying the checkpoint on the raw token-text.
That text embeds the hidden reasoning the client never replays, so the stored prefix can
never be a prefix of a future request. The checkpoint is born dead.

With --kv-disk-dir enabled and a client that switches between sessions, this means
hundreds of MiB written on every switch that are never read back, while every return to a
session keeps restarting from the older cold checkpoint. Nothing in the logs says so: the
only hint is key=token-text where you would expect key=thinking-visible.

It is easy to hit by accident. Any client that sets a tight max_tokens against a
thinking model does it on every request.

Evidence

MacBook Pro M4 Max 128 GB, macOS 26.6, Metal backend, DeepSeek-V4-Flash q2 (IQ2XXS),
single-slot server with --kv-disk-dir, two ~21k-token conversations alternated four
times through the OpenAI-compatible endpoint.

	max_tokens=48, no grace	max_tokens=48, --thinking-grace-tokens 2000
finish=stop	0 / 8	7 / 8
finish=length	8	1
stores key=thinking-visible	0	13
stores key=token-text	15	3
cache hits	always the cold checkpoint at 20480 tokens	the fresh frontiers: stored 21507 -> hit 21507, 21297 -> 21297, 21657 -> 21657

The grace fired 6 times, always at completion=48, i.e. exactly when the budget ran out
with the block still open.

For reference, with max_tokens=600 (enough for the model to close the block on its own)
the problem does not appear at all — which is what makes it easy to miss.

The two changes

1. --thinking-grace-tokens N: when the budget runs out while the block is still open,
   grant N extra tokens once, always bounded by the remaining context room, and log
   it. Default 0 keeps today's behaviour byte for byte.
2. A warning when generation ends with the block still open, reporting finish reason,
   completion, max_tokens and the grace state (off / unused / exhausted), on the
   server log and on --trace. This is the signal that was missing.

The first is a mitigation, not a guarantee: a reasoning block longer than the grace still
ends truncated (1 case out of 8 above). Closing that gap would mean injecting </think>
when the grace is exhausted, reusing the recovery path already used when a tool marker
appears inside a thinking block. Happy to add it if you prefer that shape.

Testing

make
make ds4_test && ./ds4_test --server     # server: OK

Note: ./ds4_test --server passes but does not exercise this path — generate_job is
not compiled into the DS4_SERVER_TEST build. The evidence above comes from the running
server.

No speed regression is expected: with the default 0 the added code is one boolean test
per generated token, and the new warning runs once per request.