fix: sanitize OpenAI tool schemas for strict Codex validation

[allenyoung25]

Problem

In some Claude Code -> 9router -> Codex / OpenAI flows, zero-argument MCP tools are forwarded with an object schema like:

{ "type": "object" }

Some MCP chains accept that shape, but strict OpenAI/Codex function validation does not. The request then fails with a 400 error similar to:

Invalid schema for function ... object schema missing properties

Root cause

9router currently passes tool schemas through several translator paths without normalizing zero-argument object schemas before emitting OpenAI-format function tools.

Solution

This PR adds a small shared compatibility helper for OpenAI-format tools and applies it at the translator boundaries that can emit function schemas.

The sanitizer:

• normalizes tool descriptions to strings
• converts zero-argument object schemas to the minimal strict-compatible shape:
  • { "type": "object", "properties": {} }
• recursively sanitizes nested object/array/composition schemas
• remains idempotent and avoids changing unrelated schema fields

Scope

The fix is intentionally narrow and localized.

Applied in:

• existing OpenAI-format tools
• Claude -> OpenAI tool mapping
• OpenAI Responses <-> Chat conversion
• final translator output as a last safety net

Not changed:

• routing
• auth
• provider selection
• streaming
• dependencies

Validation

• npm run test:tool-schema
• npm run build
• local regression request against /v1/chat/completions using an intentionally incomplete object schema
• verified the previously failing MCP-style tool cases no longer trigger the 400 schema validation error

[allenyoung25]

Thanks for reviewing this. This came from a real Claude Code -> 9router -> Codex failure where MCP tools exposed zero-argument input schemas as { "type": "object" } and the downstream OpenAI/Codex validator rejected them.

I kept the change intentionally narrow: the new helper only sanitizes OpenAI-format function tools at translator emission points, plus one final output safety net. That avoids touching routing, auth, provider selection, or streaming behavior.

Validation for this PR included focused schema tests, a full build, and local regression requests that reproduced the failing tool-shape case without triggering the 400 anymore.