CPU-time-limit failure risk when enabling run_worker_first for Static Assets

For a low-traffic site that serves mostly static files through a Workers Static Assets binding, the default asset-first path avoids invoking the Worker script on cacheable hits, which keeps billed CPU time low. Enabling run_worker_first restores full request control but executes the Worker before the asset lookup, adding CPU work per request and potentially surfacing the documented CPU-time-limit failure on constrained plans. A related unresolved choice is not_found_handling: when a requested asset is missing, the binding can either return a not-found response directly or fall through to the Worker, which changes both invocation count and cost for sites that mix static files with dynamic routes.

The exact behavior depends on the Workers compatibility date and Wrangler version, and the accepted values for not_found_handling differ by asset-binding setup. Before enabling run_worker_first broadly, it is unclear how to predict whether the added CPU per request will push the Worker over the CPU limit for a given plan, or how missing-asset fallthrough interacts with that limit under low traffic.

Under what request patterns does run_worker_first cause a low-traffic Worker to exceed the CPU time limit compared with the default asset-first path? How does not_found_handling affect invocation count and CPU consumption when a missing asset falls through to the Worker? What compatibility-date or Wrangler-version constraints determine the exact not_found_handling values and their interaction with run_worker_first?