fix(downloads): a download that hangs up mid-transfer is not an error at the egress gate

Seen live: yt-dlp closes a connection once it has read what it needed, and the
gate printed a traceback for each. A reset ends the tunnel quietly; anything
else the gate cannot finish is a log line with its code, not bare stderr.

backend/app/downloads/egress.py

@@ -93,6 +93,15 @@ def _read_head(sock: socket.socket) -> bytes | None:
 
 
 def _pipe(a: socket.socket, b: socket.socket) -> None:
+    try:
+        _relay(a, b)
+    except OSError:
+        # silent-ok: one side hung up mid-transfer (yt-dlp closes a connection once it has read a
+        # file's size, or gives up on a slow host); whichever side cared reports it itself.
+        return
+
+
+def _relay(a: socket.socket, b: socket.socket) -> None:
     socks = [a, b]
     while True:
         ready, _, _ = select.select(socks, [], [], _IDLE_S)
@@ -196,6 +205,11 @@ class _Gate(socketserver.ThreadingTCPServer):
     def url(self) -> str:
         return f"http://127.0.0.1:{self.server_address[1]}"
 
+    def handle_error(self, request, client_address) -> None:
+        # socketserver's default prints a bare traceback to stderr, outside the log; a connection the
+        # gate could not finish is a line with its code instead.
+        log.exception("egress gate dropped a connection", extra=logs.event("download.egress.error"))
+
 
 def start_gate(
     *, resolve: Resolver = socket.getaddrinfo, forbidden: Forbidden = urlguard.is_forbidden