Maven hosted: If-None-Match is never evaluated on GET/HEAD

Summary

Hosted Maven reads ignore If-None-Match: a GET/HEAD for a primary file or checksum sidecar answers 200 with the full body even when the request's If-None-Match matches the response's own ETag (including * and weak W/ forms). The remote (kind=2) Maven path answers a matching conditional with a bodyless 304. Confirmed on the closed-beta pre-release test run against a local build of origin/main.

Impact

• No correctness failure: Maven clients do not depend on 304, and digests verify through the sidecar path.
• Bandwidth waste for caching clients, and a hosted↔️remote inconsistency — the same request shape behaves differently on the two repository kinds although they share the URL space and emit the same ETag shape.

Expected behavior

Per RFC 9110 §13.1.2, a matching If-None-Match on GET/HEAD should answer a bodyless 304 carrying the ETag, with no download counter (no delivery) and the hosted access signal still recorded.

Fix

Prescribed in docs/specs/S10 amendment (!2023 (merged)); the implementation MR reuses the remote path's matching helpers (ifNoneMatchMatches / ifNoneMatchSatisfied).