fix(smtp-server): treat TLS read disconnects as client-gone, not errors

[kiku98]

Problem

When a client disconnects abruptly, OpenSSL and the socket layer raise errors that the SMTP server's event loop logged as genuine server errors — with a full backtrace and a Sentry report — despite being routine client-gone events (port scanners, load-balancer health checks, senders whose connection drops).

Three paths in run_event_loop were affected, each falling through to the generic rescue StandardError:

• Handshake path — a client resetting the connection mid SSL_accept raises Errno::ECONNRESET (not an SSLError), which the handshake rescue did not handle.
• Read path — an abrupt disconnect while reading on a TLS socket raises OpenSSL::SSL::SSLError (SSL_read: unexpected eof while reading) rather than an EOFError. The read rescue only handled EOFError, Errno::ECONNRESET and Errno::ETIMEDOUT, so these fell through.
• Write path — a client gone before the response is written raises Errno::EPIPE ("broken pipe") in addition to the already-handled Errno::ECONNRESET.

Fix

Extend each rescue so an abrupt disconnect on any path is treated the same as a plain-socket EOF (eof = true) — the connection is closed quietly instead of being reported as a server error:

• Handshake rescue: add Errno::ECONNRESET, Errno::ETIMEDOUT
• Read rescue: add OpenSSL::SSL::SSLError
• Write rescue: add Errno::EPIPE

No behaviour change for successful connections.