[Feat]: 0.3 compatibility

[ishymko]

Umbrella issue for defining compatibility between 1.0 SDK with 0.3 spec (note: it's not about Python SDK API compatibility, but spec compatibility for requests/responses payloads and behavior).

See a2aproject/A2A#1416 for more context.

Summary

1. 1.0 server to serve agent card which contains union of 1.0 and 0.3 fields - based on the analysis in the discussion above 1.0 agent card was adjusted to make it possible.
2. 1.0 client to consume 0.3 agent cards.
3. 1.0 server to expose 0.3 interface (per transport). Can be done via a separate path for HTTP or via A2A-Version header. Will require generating two sets of types for gRPC, given that package name of a2a.proto was updated for 1.0 spec to avoid collision (fix(spec)!: Add LF prefix to the package. A2A#1474) both services can be exported on the same port.
4. 1.0 client to consume 0.3 interface (per transport). AgentInterface now contains protocolVersion. Old agent card defines transports URLs in different fields, so client will be able to distinguish in non-ambiguous way.

Non-goals

1. Dynamically selecting push notifications payload: 0.3 sends Task and 1.0 sends same events as streaming.
2. Sending or not sending Task as a first event of resubscribe method - requirement added in 1.0 (3.1.6. Subscribe to Task)

Implementation

Given that data model changes made in the 1.0 spec mostly reshuffled existing fields the idea is to rely on transport-level mapping logic for compatibility while reusing existing domain code. a2a-go implementation: a2aproject/a2a-go#225.

It will likely require bringing back JSON Schema based types.py removed in 1.0-dev and introducing a compat subpackage similar to how it was done in A2A Go.

Client

Client already has transport concept which can contain mapping logic via a dedicated transport or a wrapper one. ClientFactory will require updating transport selection logic to take protocol versions and agent card differences into account to properly select transport: client_factory.py.

Server

JSON-RPC

JSONRPCApplication likely has to be used for this as it's the last "place" operating on non-typed request payload (which can be interpreted depending on the version). JSONRPCHandler is already typed.

HTTP+JSON/REST

The layout here is a bit different: RESTHandler still has access to raw request, so mapping can occur there. It seems that there are no HTTP paths changes between 0.3 and 1.0 which are handled one layer above in RESTAdapter.

gRPC

GrpcHandler directly implements a2a_grpc.A2AServiceServicer generated from proto. Supporting 0.3 will require generating types for old data model and service and implementing it in the same way. It is not logic heavy so reusing code via wrapping may not be necessary.