protocol: resolve TLS transport from the bound session, not thread-local io_ssl

file_send.c chose between sendfile() and the TLS-aware buffered path by
calling io_get_ssl(), which reads the thread-local io_ssl. A worker thread
that bound a TLS ProtocolSession via protocol_session_bind() never ran the
handshake in that thread, so io_ssl is NULL there and a TLS + --threads
transfer took the raw sendfile() path on an encrypted socket.

Add protocol_current_ssl(), which prefers the bound session's SSL and falls
back to io_ssl on the fd-shim path, and use it in file_send.c. Un-xfail
test_tls_with_multithreading.

src/shared/protocol.c

@@ -270,6 +270,17 @@ SSL* io_get_ssl(void) {
   return io_ssl;
 }
 
+SSL* protocol_current_ssl(void) {
+  /* The bound session is the authoritative transport for a worker thread: it
+   * was explicitly handed to protocol_session_bind() and carries its own SSL,
+   * whereas io_ssl is thread-local and NULL in a thread that never performed
+   * the handshake.  With no session bound (the fd-shim path), fall back to the
+   * legacy thread-local SSL. */
+  if (bound_session)
+    return bound_session->ssl;
+  return io_ssl;
+}
+
 unsigned long long protocol_bytes_written(void) {
   return atomic_load(&io_bytes_written);
 }