Rust: bound JSON-RPC frames and transport queues while preserving cancellation

**Package:** Rust Copilot SDK, current `main` at the time of investigation.

## Summary

The Rust JSON-RPC transport accepts peer-provided frame lengths without a configured maximum, has no deadline for completing a partial frame, and uses unbounded channels for outbound frames and inbound request dispatch. A stalled or excessively large peer frame can therefore retain transport work indefinitely or cause allocation and queue growth outside a documented resource envelope.

Add deterministic transport tests and bounded framing and queue behavior while preserving cancellation-safe shutdown.

## Current behavior

In `rust/src/jsonrpc.rs`:

- The writer uses an unbounded queue.
- Inbound request dispatch uses an unbounded channel.
- The parser allocates the message body directly from the peer-provided `Content-Length`.
- There is no maximum accepted frame size.
- There is no deadline for a peer that sends a header or body only partially.
- Frames are flushed individually. That may affect throughput, but flush batching is intentionally outside this issue.

These are confirmed implementation properties. The severity and production reachability should be determined by the transport tests rather than assumed.

## Reproduction and tests

Add in-memory or loopback transport tests for:

1. A header declaring an oversized `Content-Length`.
2. A valid header followed by a body that never completes.
3. A body delivered slowly enough to exceed the read deadline.
4. A blocked writer while callers enqueue enough messages to reach queue capacity.
5. A peer flooding inbound requests faster than the application consumes them.
6. Cancellation and shutdown while reads, writes, and queue admission are blocked.

Tests should assert bounded allocation, deterministic error propagation, and prompt cancellation rather than depending on process memory exhaustion.

## Expected behavior

- The transport rejects frames larger than a documented configurable or fixed maximum before allocating the declared body.
- Header and body reads cannot remain partially complete indefinitely.
- Outbound and inbound transport queues have documented bounds.
- Reaching a queue limit produces explicit backpressure or an explicit transport error rather than silent loss.
- Cancellation unblocks pending reads, writes, and queue admission.
- Transport shutdown completes without leaking worker tasks or dropping the final error state.
- Errors contain enough context to distinguish oversized, timed-out, closed, and backpressured transports.

## Proposed scope

Limit this issue to:

- JSON-RPC header and frame-size limits.
- Partial-frame read deadlines.
- The Rust transport's writer queue.
- The Rust transport's inbound request-dispatch queue.
- Cancellation-safe error and shutdown behavior for those limits.

The exact defaults should be chosen from observed protocol payload sizes and compatibility tests.

## Acceptance criteria

- Each reproduction has a deterministic automated test.
- Oversized frames are rejected before allocating the declared payload size.
- A stalled partial frame fails within the documented deadline.
- Queue capacity is enforced without silently dropping messages.
- Cancellation completes promptly while blocked on read, write, or admission.
- Normal request, response, notification, and shutdown tests continue to pass.
- Public configuration or error-contract changes are documented for Rust consumers.

## Non-goals

- Session-router or application-level queue limits.
- HTTP request-body streaming limits outside the JSON-RPC transport.
- Frame compression.
- Batching or removing per-frame flushes.
- A general retry policy.
- Changes to other language SDK transports in the same issue.

## Related work and non-overlap

- #1273 covers cooperative disconnect and shutdown behavior. This issue concerns frame and transport resource limits, while requiring those limits not to regress cancellation safety.

先阅读 rust/src/jsonrpc.rs，然后构建所列的内存中或环回传输测试，涵盖超大帧和停滞帧、队列压力以及取消。完成的标准是：确定性测试显示帧和队列有界、存在明确的错误或反压、取消及时、干净关闭，并且普通传输测试通过。

由索引模型根据 Issue 内容生成。