fix(main): stream hygiene for dweb fetch error paths

[meinharrd]

Follow-up to #158, addressing the two non-blocking hygiene notes from its final alan review round:

1. Abandoned body stream on error paths — the response body is now cancelled on a non-OK response, and the reader is cancelled when a chunk callback throws (e.g. ENOSPC mid-save). Previously the protocol handler would keep pulling the rest of the transfer from the gateway in the background until GC collected the locked stream.
2. Unchecked partial writes — FileHandle.write may in theory write fewer bytes than requested without throwing; sessionFetchToFile now loops until the whole chunk is on disk instead of silently truncating the saved file.

Each behavior has a unit test (body-cancel on non-OK, reader-cancel on write failure, partial-write retry loop). http-fetch.test.js + ipc-handlers.test.js: 37/37 pass locally.

[meinharrd]

[alan-review R1] No blocking findings. Verified locally on the PR branch: http-fetch.test.js + ipc-handlers.test.js 37/37 pass, eslint clean, and I confirmed the FileHandle.write(buffer, offset, length) retry-loop semantics against real Node (with 'w' and no explicit position, sequential writes advance the fd position, so resuming from the buffer offset writes the file correctly — reproduced abcdef via forced 2-byte partial writes). All three dweb error exits now cancel the stream: non-OK → body.cancel(), chunk-callback throw → reader.cancel(), timeout → the pre-existing onAbort cancel. No user-visible behavior change, so unit tests are the appropriate evidence here (no e2e/screenshot pass needed).

Two minor notes, neither blocking:

1. src/main/http-fetch.js:121-124 — write-retry loop can spin forever if bytesWritten is ever 0. while (offset < chunk.length) assumes each iteration makes progress. On regular files a >0-byte write essentially never returns 0 without erroring (quota/ENOSPC surfaces as an error on the next call), so this is theoretical — but since the loop exists precisely to handle behavior that's already theoretical, a if (bytesWritten === 0) throw new Error('write made no progress') guard would turn a hypothetical silent hang into a loud failure. Failure scenario: an exotic filesystem (FUSE/network mount) returns a 0-byte partial write; the save-image IPC handler then hangs until the inactivity timeout aborts the transfer, rather than failing with a clear error.

2. src/main/http-fetch.js:170-173, 219-222 (plus the redirect branches at 163/209) — the http(s) sibling paths still abandon the response on non-200 and on redirects. reject(...) / recursing into the redirect target never calls response.resume() or request.destroy(), so the socket lingers with unconsumed data until the inactivity-timeout handler destroys it (up to timeout ms, default 30s). This is the same hygiene class this PR fixes in the dweb path, though pre-existing, bounded by the timeout, and outside the PR's stated dweb scope — flagging per the sibling-sites lesson rather than asking for it in this PR. Failure scenario: a burst of failed http(s) image saves (404s or redirect chains) each pins a socket + buffered body for up to 30s; the dweb path no longer does.