reasoning-effort: add a fourth tier so 0731's max is actually reachable

[rell666]

Follow-up to #653, where @sleepless said he didn't mind if I opened this.

The problem

ds4 carries one reasoning-effort prefix constant, and its text is byte-identical to
DeepSeek's high string. DeepSeek-V4-Flash-0731 defines three tiers in its reference
encoder (encoding/encoding_dsv4.py, REASONING_EFFORT_PROMPTS): low (the empty
string), high, and a genuinely new max. So every ds4 tier sits one notch below its own
label, and 0731's max — the tier the published DeepSWE numbers were produced at — is
unreachable in any configuration, at any context length, with any flag.

sent to ds4	prefix emitted today	= DeepSeek tier
none	— (thinking off)	non-thinking
minimal / low / medium / high / xhigh	nothing	low
max	"Absolute maximum…" (476 B)	high
—	unreachable	max

Byte-exact, if it helps you verify your own build:

prefix	bytes	sha256
existing DS4_THINK_MAX (== DeepSeek high)	476	f7a24f3b3050d4a8…
new DS4_THINK_ULTRA (== DeepSeek max)	528	53fb31b8392ec5b4…

Both are copied verbatim from REASONING_EFFORT_PROMPTS. The ULTRA string contains an em
dash (U+2014) after "Beyond maximum" — it is part of the tokenised prompt, so it must not
be normalised to a hyphen. I re-checked both hashes against this branch's ds4.c after
rebasing, precisely because that is the byte a rebase would eat.

The design: append a fourth tier, don't renumber the three

This is the part I'd most like reviewed, because it is the whole reason this isn't a
three-line patch.

Preview's max is 0731's high string. So any fixed remap that makes max mean
0731's max necessarily sends preview users a prefix that checkpoint never saw. That is
the breakage @sleepless described in #653 as the reason he implemented a shift locally and
never pushed it.

Appending avoids it. DS4_THINK_ULTRA carries 0731's real max prefix; the three existing
enumerators keep their names and their values, so preview behaviour is bit-for-bit
unchanged. Renaming instead of appending would also have been a trap on its own: the
existing names are spelled out in ~120 literals across ds4_server.c / ds4_cli.c /
ds4_agent.c / ds4_eval.c and the tests, and a rename silently re-points every one.

Selection is one flag:

--reasoning-effort-map {deepseek|legacy}     # default: deepseek

legacy reproduces today's wire behaviour exactly, so it is a one-flag revert rather than
a rebuild. An env var would do as well — the shape matters more than the mechanism. Also
included: --think-ultra / /think-ultra to reach the tier from the CLI and the REPL, and
--think-effort-min-ctx to make the 393216-token floor runtime-settable (it accepts 0 to
disable the gate).

One behaviour change worth calling out: the context gate now steps down one tier
(ULTRA → MAX → HIGH) instead of collapsing straight to HIGH, so asking for the top tier in
a small context still reasons at the tier below rather than at no prefix at all.

Three things that bite silently — none produces a compiler warning

These will catch any implementation of this, not just mine, which is why I'd rather state
them than just hand over a diff.

1. ds4_think_mode_enabled() is an == list. Omit your new tier and thinking is
   silently disabled for it at ~25 call sites — no error, the model just stops thinking.
2. think_mode_from_enabled() does effort == MAX ? MAX : HIGH, which destroys any
   tier above MAX. A new top tier collapses straight back down unless this is updated.
3. The GLM path renders effort as a system message, and its switch has no default:.
   A new enum value silently drops its effort text there. In this branch ULTRA saturates at
   GLM's "Max"; someone with a GLM5.2 checkpoint should sanity-check that choice, as I
   can't.

Testing

Rebased onto ae504c963e and built and tested there, not on the old base — the earlier
version of this work sat on 80ebbc39 and I didn't want to offer something untested
against current main.

• Upstream main re-checked immediately before the rebase: no commit touches the
  reasoning-effort tiers.
• Conflicts were real and were resolved towards current main, not around it: main
  has since moved prefix emission into chat_push_think_prefix(), moved the legacy
  /completions path onto render_chat_prompt_text_for_syntax(), and reworked the REPL to
  track a think_prefix_pos instead of assuming the prefix sits at transcript index 1
  (which matters for GLM, whose BOS sequence pushes an extra token). Each of those is
  upstream's structure kept, with the tier table layered in.
• Built make cuda-spark on a DGX Spark / GB10 (sm_121a, CUDA 13) — clean.
• Full suite against a real DeepSeek-V4-Flash-0731 GGUF (imatrix checkpoint 202100):
  12 of 13 groups OK. server passes for both effort maps and the new tier;
  long-context, tool-call-quality and streaming-decode-prefill-correctness all pass.
• The one failure is think-tool-recovery — which is think-tool-recovery: model EOS-es after forced </think> injection — test fails with both official Flash GGUFs #675, and you closed it in
  51a1c14f a few hours after the commit this branch is based on. So it is not this
  change: on 0731 the forced think-close injects correctly and then the first sampled token
  is EOS, so the parser sees calls=0, and it reproduces byte-identically on unpatched
  80ebbc39. I'd expect it to pass on current main now, but I have not re-run the suite
  there, so I'd rather say that than imply a result I don't have.
• Unit suites (ds4_test --server, ds4_agent_test, ds4-eval --self-test-extractors,
  q4k-dot-test) all pass.
• One environmental caveat, and it is an upstream issue rather than a property of this
  branch: on a 121 GiB GB10 the suite only completes with the aligned-artifact paths
  disabled (DS4_CUDA_MOE_NO_IQ2_ALIGNED=1 DS4_CUDA_MOE_NO_Q2K_ALIGNED=1 DS4_CUDA_Q8_NO_ALIGNED=1). At default settings ds4_test is OOM-killed, because loading
  this GGUF builds ~68.6 GiB of aligned CUDA artifacts on top of the ~90.9 GiB mmap — the
  memory model in CUDA OOM regression on DGX Spark (GB10) #585. Stock main with no patch does the same thing, at the same figure.
• On the base: this sits on ae504c963e because that is what it was built and suite-tested
  on, and I didn't want to move it underneath its own evidence. main has advanced 24
  commits since. I re-checked all of them: none touches the reasoning-effort tiers —
  fe2d3b0c is the only one that even mentions a tier symbol, and only as a caller of
  ds4_think_mode_enabled(), whose two new call sites this patch's updated predicate
  already covers. It merges into current main cleanly — I tested the merge, not just
  the diff. Happy to rebase onto the tip and re-run the suite there if you'd prefer it
  that way.

Prior art, and a correction to something I said earlier

fabiopili's PR #5 to the Entrpi/ds4 fork (merged into that fork's batched-serving
branch on 2026-08-02) reaches the same diagnosis and the same mechanism independently — prefixes from REASONING_EFFORT_PROMPTS,
injected ahead of the system message, empty string for low — and cites a community vLLM
recipe for this checkpoint arriving at an identical gate condition. Three implementations on
two unrelated engines agreeing on the mechanism is better evidence than any of them alone.

It does not corroborate the design here, and I'd rather say so than overclaim: that PR
renumbers (it inserts DS4_THINK_LOW between NONE and HIGH, which shifts the
ordinals of HIGH and MAX up by one, and rewrites the call sites to match). It also keeps
the 393216-token gate, widening it to cover both prefixed tiers. That is a perfectly good
choice in a 0731-only fork, and it is exactly the choice upstream can't make without
breaking the preview checkpoint. It's a fair datapoint that renumbering is what
everyone reaches for first, and part of why I think the append variant is worth the extra
enumerator here.

Happy to split this up, drop the --think-effort-min-ctx commit, or change the flag
spelling — the part I care about is that max stops meaning high.