fix(download): treat a short clean EOF as resumable, not complete

[A831ARD0]

Follow-up to #491, which was fixed in 4.8.5 by making mid-download resume opt-in (safe default: fail and delete the staged partial file, since switching networks can route a stable URL to a different CDN object even with an unchanged validator).

The remaining gap

That fix only changes behavior for a real read error. fileDownload's copyBody loop still breaks out and promotes the file on any clean io.EOF, without checking whether the bytes written actually reached the response's Content-Length. Some transports (this app's uTLS-based client, used for TLS-fingerprint spoofing, is exactly this kind of custom transport) can surface a mid-transfer connection drop as a plain io.EOF instead of io.ErrUnexpectedEOF — so a network change mid-download could still get silently promoted as a "successful" truncated file, bypassing the new opt-in resume logic entirely (it never even reaches the canResume check).

The fix

A clean EOF short of a known Content-Length is now routed through the same resume-or-fail path as a real read error, so it respects the same resume option introduced in 4.8.5:

• Fails and cleans up the staged file by default (matching the safe-default policy).
• Resumes via Range/If-Range when the caller passed resume: true and the server provided a validator.

Tests

extension_runtime_file_download_integrity_test.go adds three tests, verified to fail on the pre-fix code and pass with it:

• TestFileDownloadShortCleanEOFFailsByDefaultEvenWithValidator — fails and cleans up by default, even with a validator present.
• TestFileDownloadResumesAfterShortCleanEOFWhenEnabled — resumes and completes correctly with resume: true.
• TestFileDownloadShortCleanEOFWithoutValidatorFails — fails and leaves no file behind when there's no validator at all.

Known follow-up (not in this PR)

fileDownloadChunked's unknown-total-size path (used for YouTube's CDN, where the total length isn't known upfront) has an analogous but harder-to-fix ambiguity: without a known length, there's no reliable way to distinguish a legitimately short final chunk from a truncated one.

Verification

• go build ./..., go vet ./..., gofmt -l — clean
• go test ./... — all green, including the 3 new tests
• Rebased onto current main after the 4.8.5 resume changes landed