feat(openapi): switch to fastapi-based generator

[leseb]

What does this PR do?

This replaces the legacy "pyopenapi + strong_typing" pipeline with a FastAPI-backed generator that has an explicit schema registry inside llama_stack_api. The key changes:

1. New generator architecture. FastAPI now builds the OpenAPI schema directly from the real routes, while helper modules (schema_collection, endpoints, schema_transforms, etc.) post-process the result. The old pyopenapi stack and its strong_typing helpers are removed entirely, so we no longer rely on fragile AST analysis or top-level import side effects.

2. Schema registry in llama_stack_api. schema_utils.py keeps a SchemaInfo record for every @json_schema_type, register_schema, and dynamically created request model. The OpenAPI generator and other tooling query this registry instead of scanning the package tree, producing deterministic names (e.g., {MethodName}Request), capturing all optional/nullable fields, and making schema discovery testable. A new unit test covers the registry behavior.

3. Regenerated specs + CI alignment. All docs/Stainless specs are regenerated from the new pipeline, so optional/nullable fields now match reality (expect the API Conformance workflow to report breaking changes—this PR establishes the new baseline). The workflow itself is back to the stock oasdiff invocation so future regressions surface normally.

Conformance will be RED on this PR; we choose to accept the deviations.

Test Plan

• uv run pytest tests/unit/server/test_schema_registry.py
• uv run python -m scripts.openapi_generator.main docs/static

[ashwinb]

This is amazing, thanks for it. It will reduce a lot of random complexity in the openapi generator.

[ashwinb]

The only comment I have is the removal of json_schema_type and not keeping some equivalent marker annotation.

In the current implementation, we use this annotations implicitly to generate a top-level "component schema" in the YAML. If we make every BaseModel be a top-level component schema, the yaml becomes harder to consume in a few places due to annoying indirection. Simple things which are just used once in the API are often best situated as inline objects
(so no $ref pointing to something else but just an inline type: object)

[ashwinb]

This is the Stainless diff (after I resolved some modify-delete conflicts)

https://github.com/stainless-sdks/llama-stack-client-python/compare/next...preview/rm-strong-typing-openapi-gen

It appears to be clean and nice, still reviewing.

[ashwinb]

It is looking quite good. Sadly we really cannot run an e2e test because the preview branches are not mirrored into the destination (production) repository (llamastack/llama-stack-client-python); they are only in the staging repositories (cc @dgellow). As a result, we cannot use our CI on the production repository to test.

I am landing this now, will check build status once Stainless updates the production repository.

CI on llamastack/llama-stack-client-python#302 is green!