Cache versions (#1034): follow-ups for untested configurations, hardening and build-step cost #1043

Follow-ups to #1034 (per-app cache versions) that are not in that PR. None blocks it. Each item says which way it fails: "cold" means a cache cleared more often than needed, "stale" means an entry served after the code that produced it changed.

Not verified

• Deployed Cloudflare worker under a host router. Local runs use miniflare. Check that entries are keyed with each router's own versions, and watch the log for the once-per-process warning getCacheVersions() prints when a store builds a key outside a request (src/server/build-version-table.ts).
• Deployed Vercel project. The preset is verified by real builds (examples/vercel-multi-router, 10 of 10 identical tables) and VercelCacheStore unit tests; the e2e runs VercelCacheStore over a file-backed handle on the node preset.
• Yarn Plug'n'Play. No node_modules, so on the node preset every dependency left external reads as "not found" and gets a new value on every build, with a build note. Cold. Decide whether to support it or document it.
• Minified RSC build (build.minify on the RSC environment). The server-reference map cannot be skipped without the bundler's region comments, so adding an action in one app changes every app's data version. Cold.
• Unminified client build (build.minify: false on the client). Client chunk names then depend on the working directory, and the document version with them. Cold.

Hardening

• plugin-rsc output shapes. The encryption-key detection, the assets manifest (serverResources), the client-reference group id and the server-reference module are matched as plugin-rsc 0.5.35 prints them (src/vite/discovery/build-versions.ts, src/vite/plugins/stable-rsc-output.ts). Each fails closed or toward a cold cache; none warns ahead of an upgrade, and the peer range ^0.5.35 admits versions these were not checked against. Option: one version check at plugin init that warns outside the verified range.
• CFCacheStore's own background tasks. Three KV-to-L1 promotions build a key after an await on the platform waitUntil, outside the re-entry ctx.waitUntil() now does. A lost context there keys with the whole-build pair: a miss, not a wrong read.
• A dependency left external whose files change while its version does not (a patched package, a git dependency at a moved ref) is not seen. Stale. Node preset only.
• A linked workspace package left external is digested whole, build artifacts in its directory included (a log, a .tsbuildinfo). Cold. Narrowing it to what files / exports reach is an open question in docs/design/per-app-cache-version.md.
• Encrypted bound arguments inside build-rendered payloads differ per build (random IV in plugin-rsc), so a router with an inline action with bound arguments inside a Prerender / Static handler gets a new version on every build. Cold. A deterministic IV would have to come from plugin-rsc.
• The encryption key is resolved once per process. Two Vite configs with different keys loaded in one process before either builds is not supported.

Cost

• The version step takes 15 to 29 ms per build (measured on four apps whose builds take 1.7 to 4 s). Candidates: the alternation-regex scan of every chunk for file names (about 9 ms on the stress demo), the extendReach rescan of the reached set, records times routers for prerender data.
• shellMemoKey builds a Request to read a URL (src/cache/cf/cf-cache-store.ts), up to twice per shell operation. Already on main; the version prefix now sits inside it.

Filed separately: #1037 (buildEnv: "auto" and the working directory), #1038 (post-processing assumes dist/rsc), #1039 (per-app client asset sets).