Bounded server-side route matching cache for lazy manifest requests

[jom-sq]

🤖 Would you consider a bounded server-side pathname-to-route-ID cache for Framework Mode's lazy manifest endpoint when the server reuses a static handler?

The current handler repeats route matching for each requested pathname. Whole-response HTTP caching helps identical URLs; a pathname cache could also reuse matching across overlapping batches when requests reach the server.

The prototype and runnable benchmark use a fresh upstream checkout and generated routes. The prototype stores only ordered route IDs, scoped to the static handler, with a 256-path LRU and a 1,024-character key limit. Assets are read for every response. Version/URL guards and document/data routing are unchanged.

With 1,001 synthetic routes on Node 26.10.0, four alternating timing rounds using object builds measured:

Request	Baseline	Prototype
Repeated 10-path batch	0.798ms	0.034ms
400-path churn	0.247ms	0.255ms

All 1,611 status/body/header comparisons passed. Four cache assertions fail before the change; 156 server-runtime tests, including all 14 new cases, pass afterward. Build, typecheck and scoped lint pass.

This is an in-process microbenchmark, not a production throughput claim. Churn is slightly slower, and retained bytes/garbage collection are unmeasured. Build callbacks, including the documented custom adapter pattern, recreate the static handler on every request and would not reuse this prototype cache. Extending reuse to callback builds needs an agreed lifetime contract.

Before pursuing a PR:

• Can routes or basename legitimately change during one static handler's lifetime?
• Would you favor this internal cache, an opt-in approach, or a different optimization?