Implement WebSocket message streaming for large payloads

[sanity]

Problem

Currently, the WebSocket client and server use large message size limits (100MB) to handle contract data. This is a workaround - the proper solution is to break up large messages into manageable chunks and stream them.

Current State

• Server-side (crates/core/src/client_events/websocket.rs): Configured for 100MB messages
• Client-side: Now also configured for 100MB to match (PR fix: increase WebSocket client message size limit to 100MB #2252)

The 100MB limit works but has drawbacks:

• Memory pressure from buffering large messages
• Potential timeout issues on slow connections
• Not scalable for very large contracts

Proposed Solution

Implement message chunking/streaming for large payloads:

1. Define chunk size - e.g., 1MB chunks
2. Chunking protocol - Add message framing to indicate:
   • Start of chunked transfer
   • Chunk sequence number
   • End of chunked transfer
3. Server-side streaming - Break large responses into chunks
4. Client-side reassembly - Reassemble chunks into complete messages
5. Backpressure handling - Flow control for slow consumers

Benefits

• Reduced memory footprint
• Better handling of slow/unreliable connections
• More predictable latency
• Scalable to arbitrarily large contracts

Related

• PR fix: increase WebSocket client message size limit to 100MB #2252: Temporary fix increasing client message size limit to 100MB

[AI-assisted - Claude]

[github-actions]

🤖 Auto-labeled

Applied labels:

• T-enhancement (95% confidence)
• E-medium (85% confidence)
• A-networking (95% confidence)
• A-contracts (80% confidence)
• S-needs-design (75% confidence)

Reasoning: The report requests replacing a large-message workaround with chunked/streamed WebSocket transfers — this is an improvement/optimization to existing functionality (T-enhancement). Implementing chunking, framing, server streaming, client reassembly, and backpressure requires moderate engineering effort across client and server (E-medium). The change primarily affects networking/WebSocket code and contract payload handling (A-networking, A-contracts). Because the issue outlines a protocol/design change (framing, flow control), it benefits from design discussion before implementation (S-needs-design). Confidence scores reflect assessment of scope and impact based on the issue description.

Previous labels: none

If these labels are incorrect, please update them. This helps improve the auto-labeling system.