fix: add recurrent TLS close_notify shutdown

[kentbull]

What

• Add recurrent ClientTls and RemoterTls shutdown through SSLSocket.unwrap().
• Drain accepted output and reject writes after close begins.
• Recur through WANT_READ and WANT_WRITE.
• Preserve TLS-buffered and final peer plaintext.
• Force-close failed sessions and dispose of the raw socket returned by successful unwrap().
• Route directional shutdown aliases through the same TLS operation.

Why

Closing the underlying socket directly can truncate accepted output and bypass authenticated TLS shutdown. A nonblocking endpoint cannot assume OpenSSL completes shutdown in one scheduler cycle.

Background

SSLSocket.unwrap() drives OpenSSL's shutdown state and returns the underlying socket when that operation completes. The protocol meaning of peer close_notify is version-specific; PR #15 supplies that TLS 1.2 versus TLS 1.3 policy.

Boundary

PR #16 later prevents premature unwrap() retry after a no-progress WANT_READ cycle. Owners remain responsible for recurring close, applying deadlines, and choosing force-close.

[kentbull]

Upstream prerequisites: #11-equivalent clean-versus-truncated TLS receive classification, #12-equivalent terminal TLS send handling, and #13-equivalent recurrent close ownership, all implemented against the accepted directional-state contract.

With those merged, SSLSocket.unwrap() can be driven recurrently through WANT states while preserving queued output and pending plaintext and disposing of the returned raw socket safely.

[kentbull]

Implements the primary downstream fix for ioflo#176: recurrent TLS close_notify shutdown through SSLSocket.unwrap(), including output settlement, WANT handling, pending-plaintext preservation, late-write rejection, fatal-error handling, and safe disposal of the returned raw socket.