fix: reject truncated downloads

[shaoohh]

Summary

• compare received bytes with Content-Length before atomically replacing the destination
• reject cleanly ended but incomplete responses as truncated downloads
• preserve an existing destination and remove the partial temporary file on mismatch
• skip the byte comparison for transparently decoded Content-Encoding responses

Root cause

The downloader handled explicit stream errors, but a response that ended cleanly before delivering its declared byte count was accepted. The partial temporary file was then renamed to the final destination, silently producing a corrupt artifact.

Impact

Image, video, and other shared downloader users no longer receive silently truncated files when a server or intermediary closes a response early.

Validation

• bun test test/files/download.test.ts
• bun run typecheck
• bun run lint (no errors; two pre-existing warnings)
• bun test
• bun run build:dev

Refs #79 (item 6: network truncation goes undetected)

---

^{Need help on this PR? Tag /codesmith with what you need. Autofix is disabled.}

[NianJiuZst]

This is a reasonable defense-in-depth check: the implementation preserves the existing destination, removes partial files, and avoids comparing decoded response bytes against compressed Content-Length values. I could not reproduce silent truncation with Node, Undici, or Bun because their fetch implementations already reject premature EOF, so I would frame this as hardening rather than a confirmed production bug; otherwise the focused and full test suites pass, and this looks good to merge once Actions are approved and green.