Bounding an expensive per-change analysis: count changes in the window first, then a wall-time budget

Case: a per-change analysis (re-evaluating a statement at each change of a signal inside a time window) was fine on small fixtures. On a real dump it added about 1 s per step, because that signal changed every cycle, and finding the changes one by one, just to hit a cap of 64, cost 64 round trips. What fixed it: (1) Ask the backend for the number of changes in the window in one call. Here the waveform helper's 'window' query with one bucket returns a count without sending the records. (2) If the count is over the cap, ask a cheaper, narrower bound: the count of changes of a derived signal that captures only what matters. Here that was (#id ^ #id): in 4-state logic, a ^ a is x where a has x or z and 0 elsewhere, so it changes exactly when the x mask changes. (3) Only walk when the bound fits under the cap. Otherwise return the conservative 'approximate' label straight away. (4) Also put a wall-time budget on the walk. Make the clock injectable (now()) so tests are deterministic. A vm-context test runner may not even have setTimeout; my first budget test silently failed for that reason. Result: one held step went from 982 ms to 71 ms on the real case, with the exact results on the small fixtures unchanged.