fix(lib): preserve custom tool calls in parse_chat_completion

[PranavMishra28]

What

parse_chat_completion() — the helper behind client.chat.completions.parse() and streaming get_final_completion() — logs a warning and then drops every custom-type tool call:

elif tool_call.type == "custom":
    # warn user that custom tool calls are not callable here
    log.warning("Custom tool calls are not callable. Ignoring tool call: %s - %s", ...)
    # <-- never appended, so the call is discarded

So a supported GPT-5 custom tool call that the model emits disappears from the parsed result — message.tool_calls omits it, and for a custom-only turn it comes back None. The raw (unparsed) ChatCompletion carries the call correctly; only .parse() loses it.

The handling is also internally inconsistent: the trailing else branch already preserves any non-function tool call by appending it unchanged — only custom is special-cased to discard.

Fix

Append the custom tool call instead of dropping it, mirroring the else branch. Custom calls legitimately don't get parsed_arguments (there's no schema to parse their free-form input against), so they're surfaced as-is. The now-inaccurate "Ignoring tool call" warning — which fired on every custom call in normal use — is removed.

Tests

tests/lib/chat/test_parse_custom_tool_calls.py (pure unit tests, no mock server / live API): a custom-only message and a mixed function+custom message. Both fail on next before this change (the custom call is dropped / tool_calls is None) and pass after. The existing tests/lib/chat/test_completions.py suite still passes; ruff and pyright --strict are clean on the changed files.

Scope / honest limitation

ParsedChatCompletionMessage.tool_calls is a generated type narrowed to list[ParsedFunctionToolCall]. With this fix a custom call round-trips through attribute access and its own model_dump(), but its custom payload is still dropped when the entire completion is serialized (pydantic serializes the list by its declared element type) — the same limitation the existing else branch already has for non-function calls. Fully fixing serialization would require widening the generated tool_calls type, which is out of scope for a lib/-only change; happy to coordinate if you'd prefer that path.

Targeted at next to match where external fixes merge.

[PranavMishra28]

leaving a note since dropping custom calls looks intentional at a glance — but the else branch just below already appends any non-function tool call as-is, so custom was actually the only tool-call type being discarded here. this just makes it consistent. custom calls have no schema to parse args against, so they pass through unchanged (no parsed_arguments), same as the else path.

[PranavMishra28]

@seratch would appreciate your eyes on this when you get a chance. small one: parse_chat_completion() drops GPT-5 custom tool calls on a custom-only turn (the raw completion keeps them, only .parse() loses them). the fix just appends the custom call instead of discarding it, mirroring how the else branch already preserves non-function calls. tests included, targeted at next. happy to adjust if you'd rather handle it a different way.