Add documentation for memory tradeoff and retry handling

Addresses code review feedback:

1. Memory Management: Document that we maintain two separate HTTP connection
   pools (with and without retries), which doubles the memory footprint.
   This tradeoff is acceptable to prevent body duplication in streaming responses.

2. Retry Logic: Add comment in stream_request.rb explaining that retry logic
   for streaming requests is handled by starting fresh requests, and the HTTPx
   connection has retries disabled to prevent body duplication.

These comments improve code maintainability by explaining the architectural
decisions and their tradeoffs.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <[email protected]>

Author: justin808

react_on_rails_pro/lib/react_on_rails_pro/request.rb

@@ -84,6 +84,10 @@ def asset_exists_on_vm_renderer?(filename)
 
       private
 
+      # NOTE: We maintain two separate HTTP connection pools to handle streaming vs non-streaming requests.
+      # This doubles the memory footprint (e.g., if renderer_http_pool_size is 10, we use 20 total connections).
+      # This tradeoff is acceptable to prevent body duplication in streaming responses.
+
       def connection
         @connection ||= create_connection
       end

react_on_rails_pro/lib/react_on_rails_pro/stream_request.rb

@@ -75,6 +75,9 @@ def each_chunk(&block)
 
       send_bundle = false
       error_body = +""
+      # Retry logic for streaming requests is handled here by starting fresh requests.
+      # The HTTPx connection used for streaming has retries disabled (see Request#connection_without_retries)
+      # to prevent body duplication when partial chunks are already sent to the client.
       loop do
         stream_response = @request_executor.call(send_bundle)