Add opt-in HVR-only peer cleanup

[Jason-Morcos]

Implements the second half of #75.

Why

On both WD53 appliances in my local setup, an unsuccessful initial certificate
handshake can stop after HelloVerifyRequest. The appliance retains that
half-open IoTivity peer on the client UDP tuple, and an immediate clean retry
can remain silent even though the endpoint is otherwise healthy.

The working recovery path sends the standard epoch-zero fatal
handshake_failure alert for that exact incomplete peer, waits outside the
transport, and then retries from the same fixed source port. This PR adds the
transport half only; the package does not choose the retry delay or perform a
retry.

What changes

• adds opt-in connect(cleanup_hvr_peer=True) for sessions using an actual
  SamsungServerProfile and a fixed non-zero local_port;
• records at most 32 datagrams/records as counters and one 13-byte outbound
  header, never handshake payloads;
• requires two complete epoch-zero ClientHellos, including one after an HVR;
• requires every received record to contain only complete epoch-zero
  HelloVerifyRequest messages;
• rejects malformed, fragmented, mixed, non-HVR, non-ClientHello, or oversized
  transcripts without sending an alert;
• sends at most one nonblocking cleanup alert after the handshake deadline;
  and
• raises HandshakePeerCleanupError, a SessionTimeoutError subclass, only
  when the complete alert datagram was handed to the UDP socket.

An ordinary timeout remains SessionTimeoutError. Cancellation, OpenSSL
failure, socket I/O failure, an inexact transcript, or cleanup-send failure do
not enter the caller's cleanup/retry path.

Validation

• 714 tests pass on Python 3.14
• focused coverage checks the exact alert bytes and record sequence, transcript
  ordering, metadata bounds, malformed and mixed records, cancellation, send
  failure, provider/port preconditions, and no automatic retry
• the shared handshake driver reports only records successfully sent
• share-safety check passes against Add authenticated server identity discovery #76's head

Merge order

This is stacked on #76 and currently includes that commit in the GitHub diff.
Please merge #76 first; this PR then reduces to commit 92ec459. #74 remains
independent. The final PY-18 API/documentation PR will stack on this one.

[QuiteYellow]

I read the cleanup mechanism back against the pinned RT-OCF tree I keep locally (Samsung/RT-OCF, last pushed 2023-04-07) and it holds. rt_ssl_error_check (messaging/transport/rt_ssl.c:373) frees the peer with ssl_remove_peer_from_list on any non-exempt negative return, and it suppresses the return alert for both MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE and MBEDTLS_ERR_SSL_BAD_HS_CLIENT_HELLO. The peer goes and the server stays quiet.

One detail you may find useful: in that tree the return code is BAD_HS_CLIENT_HELLO. While the server sits in MBEDTLS_SSL_CLIENT_HELLO it parses the record header inside ssl_parse_client_hello (ssl_srv.c:952), which rejects every content type other than handshake and returns there, ahead of the alert path. Same outcome by a different route.

That is a 2023 source reading, so your WD53s remain the real evidence. The code stands as written: the alert is the standards-correct thing to send either way.