fix: swallow client-aborted download errors after headers sent

[colachg]

Problem

GET /download/<cacheEntryId> proxies a cache entry through the cache-server when the entry is unmerged (or ENABLE_DIRECT_DOWNLOADS is off / unsupported by the storage adapter). When the runner aborts mid-stream — cancelled job, parallel runner already finished, network hiccup — the response stream's error bubbles up out of sendStream. Headers and some body bytes are already on the wire by then, so Nitro's defaultNitroErrorHandler crashes trying to write a 500 response:

[request error] [unhandled] [GET] http://.../download/<uuid>
H3Error: aborted
  cause: Error: aborted
    at TLSSocket.socketCloseListener (node:_http_client:553:19)
    ...
  code: 'ECONNRESET'

Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent to the client
  at ServerResponse.setHeader (node:_http_outgoing:642:11)
  at setResponseHeaders (file:///app/server/index.mjs:1127:20)
  at defaultNitroErrorHandler (file:///app/server/index.mjs:4227:5)
  at errorHandler (file:///app/server/index.mjs:4290:13)
  at Object.onError (file:///app/server/index.mjs:5607:14)
  ...
  unhandled: true,
  fatal: false,
  statusCode: 500,
  code: 'ERR_HTTP_HEADERS_SENT'
[cache-server-node-1]  ERROR  Response: GET /download/<uuid> > 500

It's not a process crash (fatal: false), but every aborted download produces a noisy unhandled-error log on the server, and the runner-side gets a misleading 500 response code logged after a partial download. We saw this firing many times an hour on our deployment of v9.4.7 — all from runner aborts on legitimate caches.

Repro recipe:

1. Use a storage adapter where Storage.download() returns the merge-as-side-effect proxy stream (i.e. an unmerged entry, or any storage where ENABLE_DIRECT_DOWNLOADS falls through to defaultUrl in lib/storage.ts).
2. Start a long /download/<id> and abort the client connection (curl --max-time 1 against a >100MB cache entry, or kill the runner).
3. Observe the ERR_HTTP_HEADERS_SENT unhandled error in cache-server logs.

Fix

Wrap the sendStream call in a try/catch. If the response has already started flushing (event.node.res.headersSent), log at debug and return — there's nothing more we can do with the response. If headers aren't sent yet (a true pre-flush failure), re-throw so Nitro can build a proper HTTP error response as before.

This is the smallest change that addresses the unhandled-error noise without affecting legitimate error paths.

Alternatives considered

• Guard inside Storage.download's pumpPartsToStreams.catch — also viable, but mixes HTTP-layer concerns into the storage layer. The route handler is the right place to decide HTTP-level error semantics.
• Suppress ERR_HTTP_HEADERS_SENT globally in a Nitro error hook — too broad; would hide unrelated bugs.

Testing

• pnpm lint passes locally.
• I have not run a patched build end-to-end against a real abort-mid-stream — happy to run the upstream test suite or add a route test if you can point me at the right place. I observed the error in production logs against an unmodified v9.4.7 deployment with the exact stack trace above.
• Logically: pre-flush errors (e.g. Cache file not found 404) still propagate correctly because event.node.res.headersSent is false until sendStream writes the first chunk.