feat: implement tenant-based routing

## Summary

The A2A v1.0 specification defines tenant-based routing. All REST endpoints have `/{tenant}/` prefix variants, and every request type includes an optional `tenant` field. The .NET SDK does not currently support this.

## Spec References

- **`AgentInterface.Tenant`** (proto line 345): Each entry in `supportedInterfaces` can declare a tenant ID, allowing a single well-known agent card to advertise multiple agents.
- **REST route variants** (proto lines 26-135): All endpoints have `/{tenant}/` prefix variants (e.g., `/{tenant}/message:send`, `/{tenant}/tasks/{id}`).
- **JSON-RPC**: Tenant is passed as a field in request params (e.g., `SendMessageRequest.tenant`).
- **`GetExtendedAgentCard`**: Has `/{tenant}/extendedAgentCard` variant, enabling per-tenant agent card details after authentication.

## Current State

- `MapHttpA2A` documentation explicitly notes: "Multi-tenant route variants (`/{tenant}/tasks/{id}`) defined in the A2A specification are not currently supported. The `Tenant` field on request types will always be `null` for REST API calls."
- JSON-RPC binding: `Tenant` field is deserialized from request params but not routed.
- `GetExtendedAgentCardAsync` on `A2AServer` throws `ExtendedAgentCardNotConfigured` — no built-in implementation.

## Proposed Work

### 1: REST Tenant Routing
- Add `/{tenant}/` route variants to `MapHttpA2A` for all endpoints
- Extract tenant from route parameter and populate `Tenant` field on request objects
- Pass tenant through to `IA2ARequestHandler` methods

### 2: GetExtendedAgentCard Support
- Provide a mechanism for `A2AServer` to serve per-tenant extended agent cards (e.g., a delegate or override)
- Wire `GetExtendedAgentCard` endpoint in both JSON-RPC and REST bindings

## Use Cases
- Enterprise deployments with tenant-isolated agent configurations