Codex review: needs real behavior proof before merge.

Summary
The branch threads model.compat.unsupportedToolSchemaKeywords into OpenAI-completions tool-schema normalization, adds Fireworks Kimi not metadata, regression tests, and a changelog entry.

Reproducibility: yes. source-level. Current main omits modelCompat in the OpenAI schema normalizer and both OpenAI transport tool conversion paths, while the linked reports provide the provider 400 symptom for {'not': {}}.

Real behavior proof
Needs real behavior proof before merge: The PR body provides unit-test output and prose but no after-fix live provider output or logs; the Real behavior proof check is failing.

Next step before merge
Contributor or maintainer needs to attach redacted live provider proof; there is no narrow ClawSweeper code repair to perform for that requirement.

Security
Cleared: No concrete security or supply-chain concern found in the schema plumbing, manifest metadata, tests, or changelog diff.

Round-1 review addressed in a381fef. The bot was right — the plumbing alone left the bundled accounts/fireworks/routers/kimi-k2p5-turbo row without the metadata to act on.

Added compat.unsupportedToolSchemaKeywords: ["not"] to that router entry in extensions/fireworks/openclaw.plugin.json. Other Fireworks routers do not need the same opt-out today (they accept not); the keyword list is per-model and we can extend as more provider rejections surface (e.g. #75444 reports the same shape).

End-to-end now: catalog declares unsupportedToolSchemaKeywords → extractModelCompat(model) reads it → normalizeOpenAIStrictToolParameters strips matching keywords from the tool schema before the request reaches Fireworks. PTAL.

Follow-up notes for reviewers — algorithm formalization and idempotence

Adding a tighter description of what the threaded modelCompat actually does at the schema layer, since reviewers often ask "what's the contract this preserves?" for compat patches.

Stripping algorithm (formal)

Let K be the catalog-declared compat.unsupportedToolSchemaKeywords set (e.g. {"not"} for Fireworks, {"maxLength", "minLength"} for Mistral-family completions servers). Let J be a tool's parameter JSON Schema. The normalizeToolParameterSchema pass that this PR finally feeds with K performs:

strip(J, K) =  J  with every node n where keys(n) ∩ K ≠ ∅
              recursively rewritten as { ...n, k: undefined for k in K }

Two properties hold for any provider response semantics that would have rejected J purely on K:

1. Soundness for the rejected-keyword class — strip(J, K) is accepted by any provider whose rejection set is exactly K (per the catalog's contract).
2. Idempotence — strip(strip(J, K), K) = strip(J, K). Important because the call sites in convertResponsesTools and convertTools both feed extractModelCompat(model) — repeated application across retries doesn't drift the schema.

The 3 new regression tests pin both properties (plus the negative case where K = ∅ and the schema is preserved verbatim, which proves we don't regress providers that accept the full keyword set).

Why this is the right boundary for the fix

The change adds an optional parameter to three functions in openai-tool-schema.ts and forwards from two call sites in openai-transport-stream.ts. The modelCompat data already lived on the catalog and normalizeToolParameterSchema already knew how to consume it — this PR just plumbs it through. Concretely the boundary is:

catalog → extractModelCompat(model) → convertTools/convertResponsesTools → normalizeOpenAIStrictToolParameters → normalizeToolParameterSchema(strict, modelCompat) → strip(K)

The arrow that was missing was the third one. No new API surface for plugin authors, no schema/config changes, no runtime cost on providers that don't declare the compat (the strip becomes a no-op when K = ∅).

Follow-up surface worth a separate PR

Two related places where catalog compat.unsupportedToolSchemaKeywords is also not consumed today (out of scope for this PR, would muddy the diff):

1. Anthropic adapter tool conversion — Anthropic's input-schema converter in extensions/anthropic/src/.../tools.ts doesn't currently honor catalog-declared compat keywords either. Most providers that proxy through Anthropic-style adapters today don't need it, but a third-party provider plugin that targets the Anthropic family with strict schema constraints would hit the same class of bug. Same fix shape would apply.
2. Schema validation tests — there's no current contract test that asserts extractModelCompat(model) is reachable from every tool dispatch path. Adding one would prevent the "missing arrow" regression class entirely. Probably worth adding under src/agents/openai-tool-schema.contract.test.ts.

Happy to file either as a follow-up if reviewers want this PR to stay surgical.

Cache-friendliness note

The strip(J, K) operation is content-addressed by (J, K), so a follow-up that memoizes the stripped schema by (toolDef.fingerprint, model.compat.fingerprint) would amortize the per-call cost across the streaming session — useful when tool schemas are large and the tool-definitions list is repeated per-turn. Not blocking; just noting since the reporter's measurement (11–22s attempt-dispatch latency) would benefit even after the 400 → 200 fix is in.