fix(ai): keep root object type on OpenAI-completions tool parameters

[wingwogus]

Closes #710

Summary

Function tools whose parameters schema uses a combiner (anyOf / oneOf / allOf) are sent to OpenAI-compatible backends without the root type: "object" marker, because normalizeToolParametersForOpenAICompat moves the root type into combiner branches and deletes it. Gemini-backed gateways (OpenCode Go / Zen proxying to Console) then reject the request with Invalid schema for function 'mcp__ast_grep_scan': schema must be a JSON Schema of 'type: "object"', got 'type: null'.

This change restores the root type: "object" marker at the OpenAI-completions wire boundary:

• convertTools (initial tool conversion)
• normalizeRequestToolSchemas (re-normalization after onPayload / injected tools)

The Moonshot-flavored normalizer behavior (toolSchemaFlavor: "moonshot-mfjs") is left untouched.

Test plan

• packages/ai/test/openai-completions-tool-schema-compat.test.ts: new wire-boundary tests cover both conversion paths with a scan-style type: "object" + oneOf schema, asserting the root type and oneOf survive to the actual HTTP request body.
• npx vitest run in packages/ai: 9/9 in the compat file, 1773 passed overall (1 unrelated pre-existing import failure in packages/coding-agent/src/core/tools/diff-render.ts).
• Repo pre-commit gate (npm run check) passed: Biome, pinned deps, ts-imports, shrinkwrap, install lock, full tsc --noEmit, browser smoke.

---

Summary by cubic

Restores the root type: "object" on function tool parameters sent to OpenAI Chat Completions, so schemas with anyOf/oneOf/allOf are accepted by Gemini-backed OpenAI-compatible gateways.

• Bug Fixes
  • Added ensureRootObjectType and applied it in convertTools and normalizeRequestToolSchemas.
  • Leaves $ref-rooted schemas and Moonshot-flavored normalization unchanged.
  • Added wire-boundary tests to confirm the root type and combiners persist for both initial tools and onPayload-injected tools.

^{Written for commit b6a1ace. Summary will update on new commits.}

[code-yeongyu]

[sisyphus-bot] Thanks so much for this contribution, @wingwogus — the instinct to guard the root object type was exactly right, and this PR correctly identified a real failure mode when you wrote it. 🙏

Closing as superseded by #718, which landed a fix at the normalizer layer rather than the wire boundary. Here's the concrete state on current main:

• packages/ai/src/utils/tool-schema-compat.ts:172-177 — normalizeNode now takes an isRoot flag and only calls moveTypeIntoCombinerBranches when hasCombiner && !isRoot, with the comment "The root of a tool's parameters must keep `type: "object"".
• packages/ai/src/utils/tool-schema-compat.ts:211-213 — normalizeToolParametersForOpenAICompat calls normalizeNode(..., true) then ensureRootObjectSchema.
• packages/ai/src/utils/tool-schema-compat.ts:226-233 — ensureRootObjectSchema either merges a root object union via mergeRootObjectUnion (returning type: "object") or re-adds type: "object" when the root lost it.

Because that fix lives in the shared normalizer, both OpenAI-completions entry points this PR patched (convertTools and normalizeRequestToolSchemas, openai-completions.ts:1645/1673) already inherit the guarantee — so this PR's local ensureRootObjectType is now a no-op passthrough.

It's also strictly weaker than what landed: it stamps type: "object" on the root but never merges a root union's branch properties/required up, so a tool whose parameters are a pure oneOf of object branches would ship as {oneOf: [...], type: "object"} with no top-level properties — the payload-loss case #718 explicitly fixed.

The one genuinely-still-open gap in this area is the Responses path: convertResponsesTools (openai-responses-shared.ts:536) still forwards tool.parameters unnormalized, and that's what #732 targets. If you'd like to keep contributing here, that Responses-path work is where the remaining value is. Thanks again!