A 404 under /assets is not kept for a year

[WaylandYang]

Found while running the end-to-end pass over #615's own contract, on a deployment built from it.

/assets/definitely-not-here.js     404   public, max-age=31536000, immutable

The header went on with SetResponseHeaderLayer::overriding, which does not look at the response, so the 404 for a missing asset was labelled cacheable for a year. It is the same failure chain #616 described, entering from the other end: asset names carry a content hash, so the request right after a deploy asks for the new name — and a browser that asked for it a moment too early has now been told, for a year, that it does not exist.

The header is now chosen from the status: immutable on success, no-cache otherwise.

A test, because this is the second time

The static-file mounting is now its own stateless with_static_files(app, web_dist), so it can be exercised without a database. Three tests pin status, content type and cache directive together for a served asset, a missing asset, and a page route — each of the two regressions so far would have been caught by exactly one of those three assertions, and by only one, which is why all three are asserted every time.

tower (for oneshot) and tempfile join the server's dev-dependencies; tempfile was already pinned in the workspace and unused.

🤖 Generated with Claude Code