[diegosouzapw]

Refs #10788

⚠️ base-red inherited: #9985 (release/v3.8.50 not green — unrelated pre-existing failures)

Root cause

Ollama Cloud's glm-5.1, glm-5.2, deepseek-v4-pro and deepseek-v4-flash registry
entries declared supportsReasoning: true but never declared supportedThinkingEfforts.
The catalog's appendSyncedEffortVariants() pass (open-sse/utils/syncedEffortVariants.ts)
only synthesizes selectable <model>-<tier> catalog ids from an already-populated
capabilities.effort_tiers; for static registry models that population only happens from
a non-empty supportedThinkingEfforts, and it runs before enrichCatalogModelEntry()
(src/lib/modelMetadataRegistry.ts) would otherwise derive it later. Since these four
models never declared the field, they never got a selectable -low/-high/-max
catalog id or effort selector — unlike gpt-oss:20b/gpt-oss:120b, which already declared
it and worked correctly.

Fix

Declare supportedThinkingEfforts: ["low", "medium", "high", "max"] on the four affected
models. This vocabulary is not a guess — it matches the pre-existing, in-repo documented
behavior for the Ollama Cloud provider as a whole (see supportsMaxEffortForProvider's
isOllamaCloud comment in open-sse/executors/base/reasoningEffort.ts: "Ollama Cloud
accepts low|medium|high|max|none and rejects xhigh"), which already applied uniformly to
every Ollama Cloud model (including these four) before this change, just without a
catalog-visible tier selector.

Scope

This PR intentionally covers only ollama-cloud. The originating issue also flagged
nvidia (6 reasoning-capable models) and opencode-zen as missing tier exposure, but the
triage plan-file's risk section explicitly warns against guessing per-model effort
vocabulary there — nvidia's z-ai/glm-5.2 is a documented binary enable_thinking
switch elsewhere in this codebase (mapNvidiaGlm52ReasoningParams), not a multi-tier
model, so blindly copying the ollama-cloud low/medium/high/max shape onto nvidia's other
reasoning models risks advertising tiers the upstream will then 400 on. Those two
providers need live NVIDIA NIM / opencode-zen upstream verification before a tier
vocabulary can be safely declared, and are left for a follow-up. The issue's second part
(v3.8.50 not reaching npm) is a release-engineering concern, out of scope here.

Regression test (TDD)

tests/unit/ollama-cloud-reasoning-effort-tiers-10788.test.ts — asserts the four affected
models declare non-empty supportedThinkingEfforts matching the documented
low/medium/high/max vocabulary, with gpt-oss:20b as a passing control case.

• Before the fix (verified against origin/release/v3.8.50 tip, and reproduced in the
  triage plan-file's own probe): glm-5.2 / deepseek-v4-pro / deepseek-v4-flash /
  glm-5.1 fail with "supports reasoning but declares no supportedThinkingEfforts".
• After the fix: node --import tsx/esm --test tests/unit/ollama-cloud-reasoning-effort-tiers-10788.test.ts → 1/1 pass.

Gates run locally

• node --import tsx/esm --test tests/unit/ollama-cloud-reasoning-effort-tiers-10788.test.ts → pass
• node --import tsx/esm --test tests/unit/base-executor-sanitize-effort.test.ts tests/unit/model-capabilities-registry.test.ts tests/unit/openai-responses-reasoning-effort.test.ts tests/unit/opencodeReasoningSanitizer.test.ts tests/unit/free-models.test.ts tests/unit/minimax-m3-model-registry.test.ts → 111/111 pass
• npm run typecheck:core → exit 0
• npx eslint --suppressions-location config/quality/eslint-suppressions.json <changed files> → clean
• node scripts/check/check-file-size.mjs → OK
• node scripts/check/check-complexity.mjs → OK (2573 vs baseline 2774)
• node scripts/check/check-cognitive-complexity.mjs → OK (1157 vs baseline 1223)
• node scripts/check/check-changelog-integrity.mjs → OK