fix(grpc): eliminate request_id collision in host pending responses

[octo-patch]

Fixes #7016

Problem

Each GrpcWorkerAgentRuntime starts its own per-session request_id counter
from "1". When two different runtimes both send RPC requests to agents living
on the same target runtime, the host stored pending response futures under:

_pending_responses[target_client_id][request_id]

Because both senders start from "1", both inserts share the same key — the
second overwrites the first, and the subsequent pop() raises KeyError('1').

Concrete topology (from the issue):

• Runtime-2 → relay_agent (hosted on Runtime-1): request_id = "1"
• relay_agent → inner_agent (also on Runtime-1): request_id = "1" ← collision

Solution

Before forwarding a request to the target runtime, the host now replaces the
sender's request_id with a uuid.uuid4() string. The UUID is used as the
key in _pending_responses so keys are globally unique regardless of how many
senders share the same counter values.

When the response arrives (carrying the UUID), the original request_id is
restored before the future is resolved, so the sender's own pending_requests
map can still match the response.

Changes are limited to _worker_runtime_host_servicer.py:

• Add import uuid
• In _process_request: generate a UUID, substitute it in the forwarded
  request, store (future, original_request_id) in _pending_responses
• In _process_response: look up by UUID, restore original_request_id
• Update type annotation and client-disconnect cleanup accordingly

Testing

Added test_cross_runtime_rpc_no_request_id_collision in
test_worker_runtime.py that reproduces the exact topology from the bug
report: an external runtime sends to a relay agent that in turn sends to an
inner agent on the same worker runtime, verifying the full chain completes
without KeyError.