fix(tls): reject inbound connections that present no client certificate

[sumanjeet0012]

What was wrong?

Fixes #1340

Inbound TLS connections were accepted even when the remote peer sent no client certificate. The server silently assigned a synthetic placeholder Peer ID and returned a fully-formed SecureSession, bypassing libp2p's mutual authentication requirement entirely.

How was it fixed?

The fix addresses each of the failure layers:

• Request the cert — the server-side TLS context is changed to actively solicit a client certificate during the handshake. Standards-compliant clients (Go, Rust) always send one; the cert is then available for post-handshake verification.
• Enforce the requirement — a missing certificate is now a hard rejection instead of a recoverable warning. No session is created and no data flows.
• Remove the synthetic identity — the fallback that invented a random Peer ID for unauthenticated peers is deleted from the normal path entirely.
• Preserve the AutoTLS exception — the one legitimate case (ACME broker registration, where no libp2p cert exists yet) is kept but strictly gated behind the enable_autotls flag so it cannot be reached on a standard node.
• Align exception hierarchy — TLSHandshakeFailure extends the central HandshakeFailure so TransportUpgrader surfaces SecurityUpgradeFailure on rejection.

Tests and docs

• Regression tests cover transport-level rejection, upgrader integration, and the AutoTLS primitive-exchange exception path.
• docs/tls-support.rst documents inbound mutual authentication and the AutoTLS bootstrap exception.

To-Do

• Clean up commit history
• Add or update documentation related to these changes
• Add entry to the release notes