JS bundle hash recomputed on every HTML response instead of cached #418

Description

Reassess the remaining per-request cost of JS bundle hashing. The original report said concatenated_hash() builds a full bundle string solely to hash it; that claim is outdated. The current trusted-server-js implementation streams module parts into SHA-256 and memoizes by ordered module IDs. Its own comment notes that Fastly may create a fresh Wasm instance per request, so memoization might not remove the HTML-response hash cost there. #855 also covers build-time bundle hashes and should own any shared implementation.

Proposed scope

• Measure or profile the hash work on the actual HTML response path for representative module sets and adapters.
• Determine whether build-generated constants can supply the same content-addressed URL for supported module combinations without adding runtime complexity or changing cache behavior.
• Coordinate with Per-request fixed cost: release profile, settings pipeline trim, build-time tsjs hashes #855 and close this issue as addressed or duplicate if it has no distinct remaining work.

Done when

• Current per-request hash cost and impact are documented with reproducible measurements, or the issue is closed with current-code evidence if negligible or covered by Per-request fixed cost: release profile, settings pipeline trim, build-time tsjs hashes #855.
• If a separate fix is justified, URL hashes remain byte-for-byte correct for module order/set changes and tests cover the change.
• No claim remains that the current hash path concatenates a full bundle just to hash it.

Related

The original production-readiness audit was #396.