fix(handler/forward): split readTimeout from pipe idleTimeout to prevent 15s download abort

The readTimeout field (default 15s) was being applied via xnet.Pipe to both
directions of a bidirectional proxy connection. During asymmetric transfers
(e.g. HTTP file download), the direction reading from the tunnel sees no
data after the initial request is forwarded, causing SetReadDeadline to fire
after 15s and abort the entire transfer.

Fix: add a separate idleTimeout field (default 0=disabled) to the metadata
structs in both forward/local and forward/remote handlers, and switch
xnet.Pipe to use idleTimeout instead of readTimeout. The readTimeout field
now only applies to the initial protocol sniffing/handshake phase.

Also document readTimeout vs idleTimeout semantics across all 24 locations
in the x/ module where these timeouts appear:
- readTimeout: handshake sniffing deadline (handlers), upstream response
  header timeout (http.Transport), or transport-level read deadline
- idleTimeout: idle read deadline per Pipe direction (0=disabled)
- ReadTimeout on Sniffer/SnifferBuilder: upstream response header/TLS
  handshake read timeout during sniffing

internal/util/forwarder/sniffer.go

@@ -122,6 +122,13 @@ type Sniffer struct {
 	CertPool           tls_util.CertPool
 	MitmBypass         bypass.Bypass
 
+	// ReadTimeout is the deadline for reading the upstream response
+	// headers during HTTP sniffing (http.ReadResponse) and the TLS
+	// ServerHello during TLS sniffing. This timeout is applied once
+	// per request/response pair in the HTTP keep-alive loop and cleared
+	// after each response is received. It does NOT affect the client
+	// connection or the response body transfer.
+	// Default: DefaultReadTimeout (30s) if not set.
 	ReadTimeout time.Duration
 }