measure the render path, then remember pictures instead of caching pages

The entry said to measure first and put the number in the commit, so: a plain page
renders in 14µs, a twelve-picture gallery in 1.23ms. Of that, ~102µs per picture
was reading, hashing and decoding bytes the previous request had already read.

Remembering that one fact — keyed by path, size and modification time — brings the
same gallery to 63µs. 19.5× faster, 21× fewer bytes allocated, twenty-odd lines.
After which nothing is slow enough to justify caching whole pages, so ADR-0044
declines the page cache and leaves the parked validity model parked, now with a
measurement rather than an intuition behind its trigger.

That parked model has five axes and was written before any code existed. The
problem it would have been built for turned out to be one repeated file read.

Benchmarks live in internal/web so they measure through the real handler, which is
also what conventions.md wants before any cache goes in the render path. The
invalidation risk has its own test: an edited picture is a different key, so the
memo cannot serve yesterday's dimensions. Everything runs clean under -race, since
the map is read by concurrent requests.

ideas/deferred-decisions.md

@@ -13,6 +13,10 @@ not this file, decides the shape.
 
 ## Cache validity model
 
+Status: still parked, and now with a measurement behind it (ADR-0044). Rendering a page costs ~63µs once
+repeated picture inspection is remembered; the parked model solves a problem the site does not have. Its trigger
+is a render exceeding a few milliseconds, or output that stops being a pure function of content.
+
 Deferred because no cache exists, and the harness forbids one until requests feel slow.
 
 ## Cache validity is one record with five axes