Fix video playback stalling until the entire file is downloaded

[VeloAddict]

Fixes #1304

Cause

For a request with Range: bytes=0-, DownloadController::one() computes $seekStart = 0 and $seekEnd = $size - 1, so this condition is false:

if ($seekStart > 0 || $seekEnd < ($size - 1)) {
    $out->setHeader('HTTP/1.1 206 Partial Content');
    $out->setHeader("Content-Range: bytes {$seekStart}-{$seekEnd}/{$size}");
}

The response is sent as 200 OK even though a range was requested. Separately, the response carries no ETag and no Last-Modified, and Nextcloud's default Cache-Control: no-cache, no-store, must-revalidate is left in place.

A media element seeking across byte ranges needs a validator to know that a follow-up request returns the same representation. With no validator and no-store, the browser cannot resume with a second range request, so its only option is to read the single response to completion. The 200 compounds this by not advertising range support for the response at all.

Content-Encoding: none is also set, which is not a registered content coding.

Result

The endpoint's headers now match what DAV serves. The browser buffers what it needs and drops the connection; playback starts immediately and seeking works.

Why not #1697?
#1697 caps open-ended range responses at 32 MB, which forces a 206 as a side effect of the response being partial. That works for faststart files but leaves non-faststart files unplayable — the browser receives 32 MB from the front, does not find the moov atom, and has nothing to seek toward. It also does not address the missing validator or no-store, so seeking still does not work.

[VeloAddict]

@pulsejet would it be possible to include this fix in the next release?