Close the connection when an oversized fetch is refused

[alistair3149]

Fixes #545

A response body refused for exceeding a byte cap was left unread, and node-fetch holds the connection until the body stream is either consumed or destroyed. The declared-content-length check refuses before anything subscribes to the stream, so an over-cap source URL stranded one socket for as long as the server ran. The streamed-total check already disposed of the body, because leaving the read loop destroys the stream on the way out; only the declared-length path leaked.

readCapped now destroys the body on any refusal, so the invariant holds at both cap checks and for both callers: the *-from-url upload tools and the capped SPARQL read behind wikibase-query. Only the upload path held its socket for the life of the process — wikibase-query passes a 60-second timeout signal, which eventually freed the connection on its own. Aborting the AbortController that fetchFileBytes owns would close its own connection too, but it is neither necessary nor available to postForm, whose signal belongs to the caller.

The body is narrowed with instanceof Readable rather than a type assertion: node-fetch declares it as the wider NodeJS.ReadableStream, which has no destroy(), and a body that turned out not to be a Node stream should be left alone rather than throwing a TypeError over the refusal being reported — which would also stop upload-file-from-url falling back to wiki-side copy-upload.

The regression test drives the real client against a loopback server, since the rest of the suite mocks node-fetch and cannot see a socket, and asserts that the server's end of the connection goes away. The server stalls its over-cap responses on purpose: node-fetch pumps a body that arrives complete into a buffer before the cap check runs, which returns the socket to the pool and hides the difference. An unknown route answers 404, and an assertion with no connection to observe fails rather than reading one an earlier test left behind.

To decide: whether fetchCore needs the same treatment, which this change deliberately leaves alone. It never reads a redirect response's body, so each hop leaves one behind — on the success path as well as at its three early exits (the redirect cap, a Location the guard refuses, and a cancellation between hops). Measured the same way, a 302 whose body the client never reads holds its socket indefinitely, while the socket of the hop that was followed returns to the pool. A short 3xx body is buffered whole and costs nothing, so this bites only where a source stalls or sends a large redirect body — which a caller-supplied URL can arrange. Worth its own change rather than widening this one.

Verified: the two declared-length tests fail on master (expected false to be true, the connection never closing) and pass with the fix; the streamed-total test passes on both, confirming the issue's reading of the for await path. npm run lint, npm run typecheck, npm run fmt:check and npm test (2050 tests) pass locally.

_{AI-authored — Claude Code, Opus 5 (xhigh); filed by @alistair3149, fixed by an unattended batch run with no human steering; diff not yet human-reviewed; regression test seen failing before the fix and passing after, full local suite green, CI green.}