fix(ocp-connect): revert the unknown-id fallback to 8192 — 32000 over-advertised

The previous commit raised ocp-connect's unknown-id fallback from 8192 to 32000 on
the stated grounds that 32000 was "the LOWEST max_output_tokens.default in the CLI
2.1.220 registry". That is false, and the change it justified made this PR violate
its own thesis.

Pairing-free enumeration of the compiled registry (17 occurrences, no grep-window
artifacts):

    7 max_output_tokens:{default:64000,upper:128000}
    5 max_output_tokens:{default:32000,upper:64000}
    2 max_output_tokens:{default:8192,upper:8192}
    2 max_output_tokens:{default:32000,upper:32000}
    1 max_output_tokens:{default:32000,upper:128000}

    distinct defaults: 8192 / 32000 / 64000     GLOBAL MINIMUM: 8192

The floor is 8192, held by claude-3-5-haiku and claude-3-5-sonnet — and those are
exactly the ids that reach the fallback, since "claude-3-5-*" matches none of the
family prefixes. So the raise over-advertised the only two real models the branch
serves, by 4x, in a PR whose entire claim is that advertised metadata should be true.

Verified by exercising the real classifier (verbatim source slice, not a replica):

    claude-3-5-haiku            8192  FALLBACK   registry 8192   exact
    claude-3-5-sonnet           8192  FALLBACK   registry 8192   exact
    claude-opus-5              64000  family     registry 64000  exact
    claude-sonnet-4-6          32000  family     registry 32000  exact
    claude-haiku-4-5-20251001  32000  family     registry 32000  exact
    claude-sonnet-5            32000  family     registry 64000  under (safe)

Also in this commit:

- The family table's comment said "FAMILY FLOOR of the CLI registry". It is the floor
  over each family's members CURRENTLY IN models.json, not over the registry family:
  claude-opus-4-0 / -4-5 are opus-family at 32000, so the opus row would over-advertise
  them 2x. Unreachable today (ocp-connect derives ids from /v1/models, i.e. models.json),
  but the comment now states the real scope and what to do if a legacy opus is added.

- The test table keyed haiku on "claude-haiku-4-5-20251001" while telling the reader to
  extract values id-anchored. That id has ZERO id-anchored hits: the registry record is
  id:"claude-haiku-4-5" and the dated string appears only as its provider_ids.first_party
  (10 bare-string hits). Following the instruction on that row returns nothing, which is
  precisely what pushes a reader back to the bare-string search this test exists to
  prevent. The row now carries the registry id.

Reviewer credit: the reviewer that found this also retracted its own earlier finding,
which is what produced the 32000 fallback in the first place. Both directions verified
independently here before acting.

server.mjs: unchanged by this commit (ALIGNMENT.md requires no cli.js citation).
Suite: 462 passed, 0 failed.

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

test-features.mjs

@@ -4310,9 +4310,17 @@ test("models.json: every aliases value resolves to a real models[].id (referenti
 // value above the bar and still call itself "registry-aligned" — which is the actual claim. Adding
 // a model means adding a row here, and that is the point: the row is where you record what the
 // registry said when you checked.
-const _spotRegistryMaxTokens = {           // CLI 2.1.220, id-anchored max_output_tokens.default
+// Keys are models.json ids; values are the CLI 2.1.220 registry's max_output_tokens.default,
+// each extracted id-anchored (grep 'id:"<id>"' + the following bytes) — never by bare-string
+// search, which matches cross-references inside OTHER models' records and silently attributes
+// the wrong number. ONE KEY IS NOT A REGISTRY ID: models.json carries the dated haiku id, but
+// the registry record is id:"claude-haiku-4-5" (the dated string appears only as that record's
+// provider_ids.first_party). Anchor the haiku row on the SHORT id; anchoring on the dated one
+// returns nothing, which is what tempts the next reader back into a bare-string search.
+const _spotRegistryMaxTokens = {
   "claude-opus-5": 64000, "claude-opus-4-8": 64000, "claude-opus-4-7": 64000, "claude-opus-4-6": 64000,
-  "claude-sonnet-5": 64000, "claude-sonnet-4-6": 32000, "claude-haiku-4-5-20251001": 32000,
+  "claude-sonnet-5": 64000, "claude-sonnet-4-6": 32000,
+  "claude-haiku-4-5-20251001": 32000,       // registry id: claude-haiku-4-5
 };
 test("models.json: every maxTokens equals the CLI registry's max_output_tokens.default (#195)", () => {
   for (const m of _spotModels.models) {