When a TLS ClientHello arrives without an SNI extension, we currently send a TLS alert and close the connection. Instead, if NetworkProxy is in use, we want to forward the connection to the network proxy first, and only issue the TLS error if proxying is not possible.
## Goals
- Allow TLS connections with no SNI to be forwarded to NetworkProxy when configured for any domain.
- Only send a TLS unrecognized_name alert if proxy forwarding is unavailable or fails.
## Plan
- [ ] In `ts/smartproxy/classes.pp.connectionhandler.ts`, locate the SNI-block branch in `handleStandardConnection` that checks `allowSessionTicket === false && isClientHello && !serverName`.
- [ ] Replace the direct TLS alert/error logic with:
- If NetworkProxy is enabled (global `useNetworkProxy` setting or an active NetworkProxy instance), call `this.handleNetworkProxyConnection(socket, record)` (passing the buffered ClientHello) before issuing a TLS alert.
- Supply an error callback to `forwardToNetworkProxy`; if proxying fails or no NetworkProxy is available, fall back to the original TLS alert sequence.
- [ ] Ensure existing metrics and cleanup (`record.incomingTerminationReason`, termination stats) are correctly tracked in the forwarding error path.
- [ ] Add or update unit tests to simulate a TLS ClientHello without SNI on port 443 and verify:
- When NetworkProxy is enabled, the connection is forwarded to the proxy.
- If proxy forwarding fails or the domain is not configured, a TLS alert is sent and the socket is closed.
- [ ] Run `pnpm test` to confirm no regressions and that the new behavior is correctly covered.
