fix(models): rewrite the maxTokens rationale — my justification was factually wrong

The numbers were right, the code was right, and the reason I gave for both was
wrong. Verified every part of the review's finding first-hand before rewriting.

WHAT I CLAIMED: OpenClaw caps outbound requests via
`maxTokens = Math.min(baseMaxTokens + thinkingBudget, modelMaxTokens)`, so a
16384 declaration at `high` reasoning left ~1024 tokens for the visible answer,
and raising it would produce longer answers and higher quota burn.

WHY THAT CANNOT HAPPEN FOR OCP — three independent breaks, each confirmed here:

  scripts/sync-openclaw.mjs:75   api: "openai-completions"
The clamp I cited lives behind `case "anthropic-messages"`; the
openai-completions transport has no thinkingBudget concept at all, so that code
never runs for a claude-local provider.

  buildCliArgs pushes: --input-format, --disallowedTools, --allowedTools,
                       --dangerously-skip-permissions, --mcp-config
No output-token flag of any kind reaches the CLI. OCP cannot cap output even if
it wanted to.

  grep max_completion_tokens server.mjs lib/  ->  0 occurrences
That is the field OpenClaw would send to a local openai-completions endpoint,
and this repo never reads it.

So "expect longer answers and higher per-request quota burn" was a promise that
would not have materialised. That is worse than a wrong number: a release note
that tells operators to expect a behavioural change which cannot occur.

The change still stands, on the honest reason: models.json is the SPOT (ADR
0003) and its values should be true. maxTokens is ADVERTISED metadata consumed
only by clients that choose to honour it. CHANGELOG and the test comment now
say exactly that, and say plainly that OCP behavior is unchanged.

Test replaced, not just re-worded. The old one asserted `maxTokens > 16384`,
which review showed lets every entry sit at 16385 and still call itself
"registry-aligned" — the actual claim had no coverage. Now pinned per model
against a recorded table of CLI 2.1.220 id-anchored values, with an explicit
failure for any model missing a row. Mutation-proven on both holes:

  all entries at 16385          -> CAUGHT  (the old test passed this)
  sonnet-4-6 wrongly at 64000   -> CAUGHT

Also fixed ocp-connect's unknown-id fallback (8192 -> 32000). Review flagged it
as contradicting the invariant: 32000 is the LOWEST max_output_tokens.default
in the registry, so it is the safe floor and no longer sits below every family
in its own table. Unreachable today, wrong to leave inconsistent.

Verified: bash -n on ocp-connect and py_compile on its embedded python block.
Tests: 458 passed, 0 failed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017gbqUZ8HfBZpjjbzQ85oH8

ocp-connect

@@ -147,7 +147,11 @@ def get_model_meta(mid):
     for prefix, meta in sorted(model_meta.items(), key=lambda x: -len(x[0])):
         if mid.startswith(prefix):
             return meta
-    return {"name": mid + " (OCP)", "reasoning": False, "maxTokens": 8192}
+    # Unknown id = most likely a model newer than this script. 32000 is the LOWEST
+    # max_output_tokens.default in the CLI 2.1.220 registry (haiku/sonnet-4-6), so it is the
+    # safe floor: never over-advertises a real model, and no longer contradicts the rest of
+    # this table by sitting below every family in it.
+    return {"name": mid + " (OCP)", "reasoning": False, "maxTokens": 32000}
 
 for mid in model_ids:
     meta = get_model_meta(mid)