fix(tls): correct max TLS 1.3 record length to 16640 per RFC 8446

[OneMiny]

Description

The internal Vision encryption layer previously accepted TLS records up to 17,000 bytes. This exceeds the TLS 1.3 maximum TLSCiphertext length defined in RFC 8446 §5.2, which mandates a hard limit of 16,640 bytes (2^14 + 256).

Problem

Records between 16,641 and 17,000 bytes are never produced by any compliant TLS implementation (Go crypto/tls, OpenSSL, BoringSSL, etc.). Accepting them creates a detectable fingerprint that DPI systems can use to identify VLESS Vision (PQ/decryption mode) traffic via active probing.

Per the RFC:

"The length MUST NOT exceed 2^14 + 256. An endpoint that receives a record that exceeds this length MUST terminate the connection with a record_overflow alert."

Impact

Area	Detail
Security	Eliminates a fingerprinting vector usable by DPI/active probing
Compatibility	Fully backward compatible — Write() already fragments at ~8192 bytes, well below the new limit
Scope	Only affects VLESS configurations with decryption enabled. Standard TLS/REALITY transport is unaffected (handled by Go crypto/tls)

[Fangliding]

额 那只是个简单校验 不影响啥 xray不会发 除非有第三方实现不小心弄出17000来了 不过改就改吧 影响不大

[OneMiny]

额 那只是个简单校验 不影响啥 xray不会发 除非有第三方实现不小心弄出17000来了 不过改就改吧 影响不大

Thank you for the clarification!

I believe this fix still provides value:

1. RFC Compliance: Aligns the code with the exact TLS 1.3 specification (RFC 8446 §5.2), which defines the maximum as 2^14 + 256 = 16640 bytes

2. Defense in Depth: Protects against malformed packets from third-party implementations or potentially malicious actors attempting protocol fingerprinting

3. Code Quality: Removes the TODO comment and documents the reasoning with a proper RFC reference

4. Future-proofing: As more third-party clients interact with Xray, strict validation becomes more important

I understand the impact is minimal, but since we're here, it's a small improvement that brings the code closer to the standard.