fix: preserve heterogeneous union schemas

[rajeeja]

Summary

• preserve heterogeneous oneOf / anyOf branches in Tool.parameters instead of selecting the first non-null branch
• normalize bare tuple annotations to tuple[Any, ...] so they render as JSON arrays rather than {}
• recursively remove nullable branches without removing the other accepted types
• add regressions for both float | list[float] | None and the reported tuple | float | list[Any] | None annotation

Why

Tool._normalize_parameters() used the generic flatten_schema() pipeline, which intentionally reduced multi-variant unions to their first non-null branch. This narrowed the advertised wire contract relative to the callable. If the first branch was a bare tuple (rendered as {} by the schema backend), normalization could leave the property with no JSON type at all.

Schema-driven MCP clients therefore could not send valid array values for affected parameters, despite those values passing direct Python calls and ToolRegistry validation.

Fixes #269.

Downstream report and temporary workaround: UXARRAY/uxarray-mcp-server#164.

Testing

• 138 passed in the focused schema/tool suite
• 1352 passed, 3 skipped in the full suite with test, mcp, and ptc extras
• Ruff checks and format checks pass for changed files

AI assistance

AI was used to assist with investigation, implementation, and drafting tests. I reviewed and tested the submitted changes.

[Oaklight]

Superseded by #271, which cherry-picks your commit (preserving authorship) and layers the upstream fixes on top.

The core schema-flattening fix went into zerodep (Oaklight/zerodep#173) and llm-rosetta (Oaklight/llm-rosetta#747) since the bug was in the shared libraries, not just toolregistry. Your _normalize_bare_tuple() and _resolve_enum UnionType fix are kept as-is in #271.

Thanks for the detailed issue and PR — the bare-tuple normalization was a nice catch.

[rajeeja]

Thank you!!