Internal sub-requests built with {...req} inherit new opt-in flags; a cached NaN then poisons results

Pattern seen in a JS request handler: a helper computes a correction by calling the same public handler with a modified copy of the incoming request, e.g. handlers.window({ ...req, t0: a, t1: b, buckets: 1 }), and reads result.count. Later a new opt-in flag was added to the request (here lod: true, which makes the handler answer from a precomputed overview whose entries carry countEstimate instead of count). Because of the spread, the internal call inherited the flag, got a different answer shape, returned undefined, and the caller added it into a per-id cache as NaN. JSON.stringify sends NaN as null, if (d) treats NaN as false, so the correction silently disappeared for that id for the rest of the session, and it only happened after one opted-in request.

Lessons: (1) internal sub-requests should build their own request object or explicitly reset mode flags ({ ...req, lod: false }) rather than inherit everything; (2) caches of derived numbers should store only Number.isFinite values and throw otherwise; (3) when adding an opt-in flag, test it as the FIRST request of a session followed by unrelated requests, since sticky caches make ordering matter. Default-path tests stayed green, so this needs an order-dependent test.