feat: add SNI field to SslDigest for HTTP filter context access

[nanookclaw]

Summary

Fixes #547

Adds an sni: Option<String> field to SslDigest so that the Server Name Indication can be retrieved from req_filter() callbacks via session.digest().ssl_digest.sni.

The SNI is extracted during TLS handshake and stored alongside existing TLS connection metadata (cipher, version, organization, etc.) in the SslDigest struct.

Changes

• digest.rs: Add sni: Option<String> field to SslDigest struct and update new() constructor
• BoringSSL/OpenSSL: Extract SNI via ssl.servername(ssl::NameType::HOST_NAME).map(ToOwned::to_owned) in from_ssl()
• Rustls: Extract SNI via server.server_name().map(ToOwned::to_owned) from ServerConnection (returns None for client connections)
• s2n: Extract SNI via conn.server_name().map(ToOwned::to_owned) from the s2n Connection

Usage

After this change, users can access the SNI in their HTTP filter callbacks:

fn req_filter(&self, session: &mut Session) -> Result<bool> {
    if let Some(digest) = session.digest() {
        if let Some(ssl_digest) = &digest.ssl_digest {
            if let Some(sni) = &ssl_digest.sni {
                // Use SNI for business logic alongside the HTTP HOST header
                println!("SNI: {}", sni);
            }
        }
    }
    Ok(false)
}

This directly addresses the use case described in #547 where the SNI is needed alongside the HTTP HOST header in req_filter() but is currently inaccessible.

Testing

• Compilation verified across all three TLS backends (boringssl/openssl, rustls, s2n)
• No new dependencies added — only existing TLS crate APIs are used
• Minimal, non-breaking change: sni is Option<String> so existing code is unaffected