Multicast RPC: no mechanism to route follow-up messages to the correct per-agent context

## Problem

In all multicast RPC methods (`SendMessage`, `SendStreamingMessage`, `SendLiveMessage`), each participating agent creates its own `Task` with its own server-generated `contextId`. A client that fans out to N agents therefore receives N tasks with N independent `contextId` values.

The A2A specification defines `contextId` as server-generated and opaque to clients (§3.4.1). As a result, a client that wants to send a follow-up message to an ongoing multicast session has no standard way to route each copy of the message to the correct per-agent context.

## Proposed solution

Introduce a `slimrpc-context-map` SLIMRPC metadata key: a JSON object mapping each agent's SLIM name to the `contextId` that agent assigned during the initial multicast call.

The SLIMRPC transport rewrites the `contextId` field of each outbound message to the destination agent's value from this map before delivery. This is transparent to agents — each agent sees its own `contextId` as if the message were a normal point-to-point call.

**Flow:**
1. Initial multicast call — no map needed; each agent generates its own `contextId`.
2. Client records `{ agentSLIMName → contextId }` from each agent's first response.
3. Follow-up messages include `slimrpc-context-map` in SLIMRPC call metadata.
4. SLIMRPC transport rewrites `contextId` per-agent before delivery.

This approach is already specified for `SendLiveMessage` (fan-out and broadcast modes) in [slimrpc-multicast.md §8.4](spec/v1/slimrpc-multicast.md). This issue tracks applying the same mechanism to `SendMessage` and `SendStreamingMessage`.