An app's page served with the forge toolbar keeps a validator, so a signed-out revisit is a 304 instead of the whole page #9136

Intent: every app the forge serves gets the toolbar (P6), and the toolbar should not cost the app its conditional requests: today a revisit to any app page always downloads the whole body.

Today src/apps/proxy.ts (~line 1269) rewrites an HTML response to add the toolbar and then deletes its etag (and content-md5). Production shows it: curl -D - https://lab--forge-trevato-apps.open-platform.sh/explore answers 200 with no etag, though the app's own src/web/layout.ts tags that signed-out page by its bytes. src/http/etag.ts has weakEtag and holds.

Done looks like:

• [x] When the upstream HTML carried an etag and the rewritten page is the same for every viewer (no proof, no per-person pill), the proxy sends a weak etag that changes when either the upstream tag or the injected toolbar changes (e.g. the upstream tag joined with a hash of the toolbar markup).
• [x] A request whose If-None-Match holds that tag is answered 304 with no body by the proxy; the proxy forwards the upstream part of the tag so the app can answer 304 itself, or compares after fetching — either way no stale toolbar is ever kept.
• [x] A page marked private, no-store (the proof path), a signed-in viewer's page, and any non-200 carry no etag, as today.
• [x] A test beside the proxy's tests serves a tagged HTML page through the proxy: first 200 with an etag, repeat 304; a changed upstream body or a changed toolbar gives 200 with a new tag; a proof page has no tag.

Files: src/apps/proxy.ts, one test. Risk: gzip varies by client — a weak tag is right since only the encoding differs; never let a 304 pair an old toolbar with a new forge.

Reviewed pull #9139 at its head: ticked When the upstream HTML carried an etag and the rewritten page is the same for every viewer (no proof, no per-person pill), the proxy sends a weak etag that changes when either the upstream tag or the injected toolbar changes (e.g. the upstream tag joined with a hash of the toolbar markup).; A request whose If-None-Match holds that tag is answered 304 with no body by the proxy; the proxy forwards the upstream part of the tag so the app can answer 304 itself, or compares after fetching — either way no stale toolbar is ever kept.; A page marked private, no-store (the proof path), a signed-in viewer's page, and any non-200 carry no etag, as today.; A test beside the proxy's tests serves a tagged HTML page through the proxy: first 200 with an etag, repeat 304; a changed upstream body or a changed toolbar gives 200 with a new tag; a proof page has no tag..