Test the range probe fallback and a 204 cache answer

What does this MR do?

Follows up !7678 (merged) with the three non-blocking suggestions Lachlan Grant made when he approved it, as he wrote them:

• Add a test for the path in #40111 (closed) with FF_USE_PARALLEL_CACHE_TRANSFER on and an object that fits in one chunk, where the bytes=0-0 probe falls back to the sequential GET (!7678 (comment 4187731560)).
• Add a test for a 204 to the GET without Range (!7678 (comment 4187731666)).
• Change two older comments that still said the sequential download keeps a replayed partial 206 as the archive (!7678 (comment 4187731764)).

Why was this MR needed?

The tests of !7678 (merged) set no feature flag and send only a 206. A later change to the probe or its fallback could bring the bug back, and a check narrowed to == http.StatusPartialContent would let a 204 write an empty archive again, while every test still passed.

What's the best way to test this MR?

go test -race -count=1 -run 'TestCacheExtractorRemoteServer' ./commands/helpers/

What I ran

• go build ./..., go vet on ./commands/helpers/ for Linux, Windows and macOS, and go test -race -count=1 ./commands/helpers/ with Go 1.26.10 and TZ=UTC: pass. The two new tests and TestCacheExtractorRemoteServerRejectsPartialContent, -race -count=20: pass.
• Both new tests fail with the commands/helpers/cache_extractor.go of main before !7678 (merged) (06d1ba77): An error is expected but got nil.
• With the check narrowed to == http.StatusPartialContent, the 204 test is the only test of ./commands/helpers/ that fails.
• make lint in the runner-linters:2.14.0-go1.26.10 image main uses: 0 issues., test directives included.

What are the relevant issue numbers?

Related to #40111 (closed).