Define consistent tenant-field handling for JSON-RPC and HTTP+JSON

## Context

Follow-up to #418; related to #368.

The agreed design direction from the #418 review discussion is that explicit tenant parameters are for gRPC. JSON-RPC and HTTP+JSON select the tenant-specific agent through its URL, with routing owned by the host application. This records the SDK design direction, rather than asserting that all published specification text already reflects it.

#418 remains scoped to flattening push notification configuration. It clears the body tenant for standalone REST push-config creation and corrects the REST documentation, but does not establish a binding-wide tenant-field policy.

## Remaining inconsistency

- Other body-bearing REST operations, including SendMessage and streaming SendMessage, forward request tenant fields unchanged.
- JSON-RPC also forwards tenant fields in request parameters.
- Shared request models expose Tenant, and HTTP clients can serialize it.
- #368 proposes populating request Tenant from REST routes and describes explicit JSON-RPC tenant parameters; that proposal needs reconciliation with the agreed URL-based approach.

## Scope

- Define one consistent policy for explicit tenant fields in both HTTP bindings: omission on outgoing requests and rejection or ignoring on incoming requests. Decide the compatibility behavior explicitly; do not silently change routing context.
- Ensure body/params tenant fields cannot override the agent identity selected by the host URL/routing.
- Cover unary and streaming operations, standalone push-config operations, and embedded push configurations.
- Retain explicit tenant parameters for gRPC and avoid removing shared model fields required by that binding.
- Review v0.3 compatibility adapters where they intersect with the policy.
- Document host-configured tenant-specific agent URLs without prescribing a fixed URL layout.
- Reconcile the overlapping proposal in #368.

## Acceptance criteria

- JSON-RPC and HTTP+JSON have a documented, consistent tenant-field policy.
- Serialization and server-dispatch regression coverage includes supplied, omitted, and conflicting tenant values and unary/streaming paths.
- URL-selected agent identity is not overridden by request fields.
- gRPC's explicit tenant representation remains supported.
- Documentation describes actual behavior without claiming that every REST request Tenant field is already null.

Review the shared request models exposing the Tenant field, the JSON-RPC parameter handling, and HTTP bindings for operations like SendMessage. Examine the routing logic to understand how the agent identity is selected from the URL. The goal is to define a policy that prevents request fields from overriding URL-based routing, while maintaining gRPC support. Check existing tests for serialization and dispatch to ensure coverage.

Rédigé par le modèle d'indexation à partir du texte de l'issue.