fix(openapi): remove auto-generated Python-like titles from union sch…

[r-bit-rry]

Draft Status

This PR is a draft pending Stainless SDK preview validation. We need to verify that removing these titles doesn't cause regressions in generated SDK type names.

Explores the removal of auto-generated Python-like titles (e.g., title: list[string], title: string | list[string]) from inline union schemas in OpenAPI specs.

Problem

The _add_titles_to_unions() function was generating titles that look like Python type hints rather than human-readable labels. These titles:

1. Redundant information: The type info is already expressed in the schema structure (anyOf, type: array, items). The title just duplicates it in a different syntax.
2. Wrong audience: title is intended for human readability in the API docs, I'm not sure yet about how title is used by the generators. Someone reading title: string | list[string] needs to know Python syntax to understand it.
3. Not what JSON Schema intended, from the spec: "The title can be used to decorate a user interface with information about the data produced by this user interface." documentation claims its not intended for type signatures.
4. Tooling confusion: Some OpenAPI tools use title for display names in generated documentation.

Introduced in PR #3944. The intent was good, help Stainless generate better type names instead of ugly ones like UnionMember4. But the implementation produces Python-like syntax (list[string]) which was identified as "off".

Solution

Made _add_titles_to_unions() a no-op. Named schemas retain their proper titles via @json_schema_type and register_schema().

Fixes #4670

BREAKING CHANGE: Changes to schema generations

[mergify]

This pull request has merge conflicts that must be resolved before it can be merged. @r-bit-rry please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[leseb]

I suspect that we do get proper titles for anyOf and oneOf thanks to the migration to FastAPI routers.
So we should remove this function once we are done with the migration.

Can you hold until that happens?

[mergify]

This pull request has merge conflicts that must be resolved before it can be merged. @r-bit-rry please rebase it. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork