Recover host name from the TLS ClientHello SNI when the target is an IP - #689

Under full-system / SOCKS5 capture the connect authority is often a raw IP, so
the generated certificate gets an IP CN and the recorded host is the IP. The real
host name is in the client's TLS ClientHello SNI.

Add an opt-in RecoverHostNameFromSni setting (default off). When enabled and the
connect target is an IP, both ingress providers (SOCKS5 and transparent CONNECT)
peek the ClientHello up front, parse the SNI, and adopt it for the recorded
authority and the upstream SNI while pinning the original IP via RemoteHostIp, so
the upstream connection still targets it exactly with no extra DNS and no reroute.
The peeked bytes are replayed, so the handshake (decrypt) or the tunnel (blind) is
byte-for-byte intact. Because the host name is known before the blind/decrypt
split, blind tunnels also get the host name recorded.

Parsing is bounded and never throws: no SNI, ECH, malformed or over-large input
falls back to the IP authority. The peek is bounded by a timeout so a silent
client on a non-TLS blind tunnel forwards normally instead of stalling.

Surfaced on the CLI as --recover-host-from-sni.

…ection

The pin was set on the provisional exchange context only, while the
exchanges that actually reach upstream get a fresh context from the
downstream pipe, so decrypt mode re-resolved the SNI host through DNS.
A decorating context builder now pins the original IP on every context
created for the connection, unless a rule already forced a remote IP.

The ClientHello peek also runs before the exchange context is built and
the context is created with the recovered authority, so rules evaluated
at OnAuthorityReceived scope match the host name instead of the IP. The
flag is passed to the source providers at construction.