[Feat]: Generate Pydantic models from proto definition for Python-idiomatic validation for A2A Version 1.0.x

The issue is about generating Pydantic models from the a2a.proto file. Look at the existing build pipeline (likely using buf and protoc) in the repository. Research tools like protobuf-to-pydantic. The work involves modifying the build system to produce an additional artifact. 'Done' means the generated Pydantic models are published in the SDK package alongside the proto types.

Is your feature request related to a problem? Please describe.

The migration to protobuf-generated types (PR #572) removes Pydantic models entirely from the SDK. While using a2a.proto as the single source of truth is the correct architectural decision, the removal of Pydantic models creates a significant developer experience gap for the Python ecosystem.

The problem:

1. FastAPI, the most widely used Python web framework for building AI/agent services, uses Pydantic natively for request validation, serialization, OpenAPI schema generation, and error reporting. Proto objects don't integrate with any of this. Developers lose automatic validation, clear error messages, .model_dump(), .model_validate(), union discriminators, and Field() defaults.

2. Protobuf objects in Python are not idiomatic. WhichOneof(), HasField(), CopyFrom(), MessageToDict()/ParseDict() are foreign patterns to Python developers building agents with LangChain, CrewAI, or custom FastAPI services. Proto3 has no required fields, so ParseDict({}, SendMessageRequest()) succeeds silently with an empty object, providing no validation at all.

3. The v0.3.0 Pydantic types (generated from the OpenAPI spec via datamodel-codegen) were well-received and widely adopted. Multiple community frameworks depend on them for HTTP-layer validation. Removing them without replacement forces every downstream project to either vendor their own type definitions or wrap proto objects with manual validation boilerplate.

4. This is visible in the issue tracker right now: #876 "SDK doesn't validate proto..." and #856 "Server does not validate..." are direct consequences of losing Pydantic's validation layer.

Describe the solution you'd like

Generate Pydantic models from the proto definition as an additional build artifact, alongside the existing proto-generated types. Both would be published in the SDK package.

Concretely:

• a2a.types.proto (or a2a.grpc): Proto-generated types from a2a_pb2, as implemented in PR #572. Used by gRPC transport and anyone who prefers proto-native patterns.

• a2a.types (or a2a.types.models): Pydantic models generated from the same a2a.proto source. Used for HTTP/JSON validation, FastAPI integration, and Python-idiomatic development.

Generation can be automated via protobuf-to-pydantic, custom protoc plugin, or a build script that derives Pydantic models from the OpenAPI/JSON schema (which is already generated from the proto via buf). The key point: a2a.proto remains the single source of truth. The Pydantic models are a generated artifact, not a manually maintained parallel type system.

This is not an either/or decision. The proto types serve gRPC consumers well. The Pydantic types serve the HTTP/JSON/FastAPI ecosystem. Both are generated from the same source, stay in sync automatically, and serve different transport layers of the same protocol.

The cost is one additional codegen step in the build pipeline. The benefit is that the Python SDK remains usable for the majority of Python agent developers who build on FastAPI/Pydantic.

Describe alternatives you've considered

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct