GET /api/v1/feed answers 304 only when nothing the viewer would read has changed: events, shares, dismissals, mutes, chips and the minute #6218

Replaces #5875. Pull #5886's branch has most of this already: start from it. Three reviews said what was still missing, and this lists it.

Done when:

• [ ] The weak ETag (src/feed/feed_tag.ts) is built from the viewer, the switched-off chips, the cursor, the limit, the newest event the viewer can see, and the viewer's newest share, dismissal and mute rows, and a minute bucket of now. now can be injected for tests. It is never derived from the body.
• [ ] A viewer with queued shares never gets a 304: drain the queue first (as readFeed does), or answer 200.
• [ ] A matching If-None-Match answers 304 with no body and with the security headers. render is absent from its Server-Timing.
• [ ] Tests in test/feed-etag.test.ts pin the clock with setSystemTime in beforeAll and reset it in afterAll. They cover: 200 then 304; 200 after a new event; 200 after a share, a dismissal and a mute; 200 once the clock crosses into the next minute, and once a pull crosses the 24 h wait line (src/web/studio/asks.ts WAIT_LIMIT_MS); a different chip or limit gives a different tag; two viewers and a private repository only one of them can see.
• [ ] The doc comment sits on feedTag, and TAG_BUCKET_MS has a one-line comment of its own.

Files: src/feed/feed_tag.ts, src/http/feed.ts, test/feed-etag.test.ts.