`304 Not Modified` for unconditional request

In certain situations, the server responds with a 304 Not Modified status code for a request that lacks any specific conditions.

Reproduction steps:

{
    log
    cache {
        stale 3600s
    }
}

http://localhost:80 {
    log
    cache
    reverse_proxy http://localhost:82
}

http://localhost:82 {
    log
    header Cache-Control "max-age=1"
    file_server {
        root /data/caddy/
        index instance.uuid
    }
}

$ curl -i-H 'Cache-Control: max-stale=6' localhost:80
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=1
Cache-Status: Souin; fwd=uri-miss; stored; key=GET-http-localhost-/
Content-Length: 36
Date: Fri, 26 Dec 2025 12:28:54 GMT
Etag: "df7g3dt1b7k010"
Last-Modified: Thu, 25 Dec 2025 16:40:49 GMT
...

$ curl -i-H 'Cache-Control: max-stale=6' localhost:80
HTTP/1.1 304 Not Modified
Cache-Control: max-age=1
Cache-Status: Souin; fwd=request; fwd-status=304; key=GET-http-localhost-/; detail=REQUEST-REVALIDATION
Date: Fri, 26 Dec 2025 12:29:26 GMT
Etag: "df7g3dt1b7k010"
...

Start with the Caddyfile and curl reproduction in the issue, comparing the first successful response with the later 304 response and its request headers. Trace the cache and reverse-proxy handling involved in REQUEST-REVALIDATION; done means an unconditional request no longer receives an unexpected 304 response.