Fix XHTTP regression: drop download-reject guard, widen reorder buffer

The single-download guard added earlier rejected a second stream-down GET for a
session with HTTP 400. On a client reconnect (network hiccup / H2 retry) while
the previous download handler is still blocked on a dead socket, that 400 makes
the client tear the whole session down and every retry keeps failing -- the
tunnel stops passing data entirely. xray-core never rejects a re-GET, so remove
the guard and match it.

Also raise the default XHTTP packet-up reorder buffer from 30 to 512. xray-core
uses 30 because its own client sends POSTs near-in-order, but other clients fan
out many concurrent POSTs that arrive well out of order; 30 tripped the
reassembly-too-large teardown and stalled traffic. The per-inbound
scMaxBufferedPosts still overrides this.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

xray_native_tuning.go

@@ -34,11 +34,14 @@ const (
 	fixedNativeMuxUDPWriteBuffer = 256 * 1024 // mux UDP socket write buffer
 
 	// XHTTP: max tracked sessions (DoS guard) and the packet-up reorder buffer.
-	// defaultNativeXHTTPBufferedPosts matches xray-core's scMaxBufferedPosts
-	// default; the per-inbound scMaxBufferedPosts from the config still overrides
-	// it, exactly like upstream.
+	// The per-inbound scMaxBufferedPosts from the config still overrides this.
+	// xray-core's own default is 30 (its client sends POSTs near-in-order), but
+	// other clients (v2rayNG/nekobox/etc.) fan out many concurrent POSTs that can
+	// arrive well out of order; a small buffer then trips the reassembly-too-large
+	// teardown and stalls traffic. Keep a generous default so reordering is
+	// absorbed rather than fatal.
 	defaultNativeXHTTPMaxSessions   = 16384
-	defaultNativeXHTTPBufferedPosts = 30
+	defaultNativeXHTTPBufferedPosts = 512
 )
 
 var (