Keep request max-age within response freshness lifetime

[kokotatan]

A request with Cache-Control: max-age=3600 currently replaces the stored response's freshness lifetime. A response with max-age=60 that is already 120 seconds old is therefore returned from cache. The same happens when its freshness lifetime comes from Expires, including explicitly expired 301/308 responses.

Limit the existing response lifetime with the request's max-age instead of replacing it. RFC 9111 section 5.2.1.1 defines request max-age as an acceptable age bound and distinguishes permission to receive stale responses through max-stale. A larger request max-age does not make an expired response fresh.

This also means an ETag-only response without a freshness lifetime is revalidated even when the client supplies max-age. Its cache entry and conditional validator remain available. The existing heuristic redirect fallback and the library's existing handling of other request directives are unchanged.

Validation on Windows / Python 3.12:

• Six controller regressions for response max-age/Expires and status 200/301/308 fail before the fix.
• A real local HTTP server regression and an ETag-only regression also fail before the fix.
• Full test suite: 125 passed, 85% overall coverage.
• Ruff lint, strict mypy (12 source files), Sphinx HTML build, changed-test formatting and git diff --check: passed.
• Repository-wide format check reports two existing docstring formatting differences; both reproduce on the unmodified files. Codespell reports two existing unparseable spellings (and generated documentation when scanning the working tree). Those unrelated files/lines are unchanged.

AI assistance: developed with OpenAI Codex and checked through independent Claude Opus and Codex AI reviews. This does not claim human review.