Entries cached with ttl=None can answer 304 indefinitely #110

Problem

With @cache(ttl=None) the entry is stored without expiry. A request whose If-None-Match matches the stored fingerprint gets a 304 without running the handler. After the data changes, a client that keeps revalidating with the old ETag keeps getting 304 until some other request rewrites the entry. Entries also never expire, so query-string variants accumulate without bound on the Memory backend.

Proposal

For ttl=None, render and compare (the no_cache path) instead of answering 304 from the stored fingerprint, or do not store at all. At minimum document both effects in HTTP_CACHING.md.

Changes behaviour but no API; to be decided whether it counts as a fix.