Per-request fixed cost: release profile, settings pipeline trim, build-time tsjs hashes #855

Context

This issue came from the 2026-07-05 performance and architecture review. It grouped release artifact size, configuration work per request, and TSJS hashing into one performance follow-up. Treat the old figures as historical observations: the review reported a 53.5 MiB artifact, about 45.6 MiB of DWARF, and a 5.3 MiB code section, and projected a 15–30% code-size reduction. Those figures and that projection have not been remeasured on current HEAD.

Some cited TSJS work has changed. Matching content-versioned TSJS requests already receive public, max-age=31536000, immutable; mismatched versions keep a short TTL (publisher.rs). trusted-server-js/build.rs emits per-module SHA-256 values. The concatenated module-set hash is still computed from bundle bytes and memoized in bundle.rs; its comment notes Fastly creates a fresh Wasm instance per request. The workspace release profile still sets debug = 1 and has no explicit LTO/strip setting in Cargo.toml.

Desired outcome

Reduce measured release artifact size and request fixed cost without weakening configuration validation, cache correctness, or startup behavior.

Scoped work

1. Release profile: Measure the current Fastly WASM artifact by section and record build time and request performance. Evaluate strip, LTO, codegen-unit, and optimizer options one at a time. Keep only settings with a measured benefit and acceptable build/debug tradeoffs.
2. Configuration pipeline: Profile the current production request path to locate repeated config-store reads, envelope checks, parse/validation, regex compilation, registry construction, geo lookup, or signing-key decoding. Remove or cache only confirmed duplicate work. Any trusted-blob fast path must retain integrity, version, compatibility, and unsafe-config rejection guarantees.
3. TSJS hashing: Measure the remaining concatenated module-set hash cost for actual HTML paths and Fastly instance lifetime. If material, derive the exact concatenation hash at build time or use an equivalent safe cache keyed by the enabled immediate module set. Preserve the current matching-versus-mismatched URL cache policy.

These are independent changes and can ship as separate PRs with their own before/after evidence.

Done when

• Baseline measurements identify which of the three areas still has material cost on current HEAD, with a reproducible command or benchmark setup.
• Each change shipped under this issue has a measured before/after result and preserves the relevant correctness tests.
• Release artifacts still build for the supported Fastly target; config loading still rejects invalid or tampered data; TSJS version hashes still match the served bytes for each module set.
• Already-completed cache-policy and per-module-hash work is acknowledged in the final PR/issue summary, with no duplicate implementation.