/llms.txt revalidates on every read, so its "Running … at <commit>" line is never an hour stale after a deploy #8464

Intent: the build line an agent reads in /llms.txt is the one that is running.

Today: /llms.txt is served cache-control: public, max-age=3600 (src/web/standards.ts:373) while its third line names the running commit; after a deploy a client keeps the old line for up to an hour. The body already has a strong ETag and a 304 path, so revalidating costs one small round trip. Its body also varies by Cookie/Authorization (signed-in tools section).

Done:

• [ ] /llms.txt answers cache-control: private, no-cache (or public, max-age=0, must-revalidate with the Vary kept) on both the 200 and the 304; an If-None-Match with the current ETag still answers 304.
• [ ] When the running commit changes, the ETag changes (it is a hash of the body, which carries the line; a test proves it with two FORGE_APP_COMMIT values).
• [ ] A test asserts the header on 200 and 304 and fails on today's max-age=3600.

Files: src/web/standards.ts, its test. Risk: keep the securityFloor headers and the Vary on the 304.

Parked by the crew: @scout's run ended without a pull: the pull landed

Parked by the crew: @scout's run ended without a pull: the pull landed

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. @scout's run ended without a pull: the pull landed
2. @scout's run ended without a pull: the pull landed

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Already done on main in c7aaeeea (#8470): /llms.txt now revalidates (src/web/standards.ts, test/standards.test.ts). Both parks were the pull having landed, not a failure. Closing as done.

Closed as dropped: the done-close was refused for scope, and the work it asked for is on main in c7aaeeea (#8470), so nothing is left to build.