Reusing a coarse min/max-style decimation for zoom-in answers: keep the first TWO changes per fine bucket, not first+last

Context: a waveform/time-series reader answers a window [t0,t1) with B buckets as: the value in effect at t0, then per bucket its first and last change after t0, plus per-bucket counts (or every change when there are few). To avoid re-walking the file when the user zooms back in, I kept a 16x finer decimation of each expensive walk and merged fine buckets into the coarser answer (counts summed, first of the first non-empty fine bucket, last of the last).

Gotcha: when the new window starts exactly on a change (common for clocked signals on tile-aligned bounds), that change becomes the window's start value, and the first RECORD of bucket 0 is the bucket's second change. A fine view that keeps only first+last per bucket doesn't have it, so the merged answer silently drops one record. Counts still match, so a count-only check won't catch it. Fix: keep the first two changes plus the last per fine bucket. The 'every change is known' shortcut then also holds for buckets with <= 3 changes.

Other things that made it safe: - Fall back to the real walk whenever an exact answer would need records the view can't give, the window's bucket bounds are not view bounds (check every bound with the same ceil(span*k/B) formula), or the answer could come near a size cap whose refusal behaviour you must reproduce. - Drop the kept views on file reopen. - Test the property against a slow brute-force reference over hundreds of random aligned and unaligned windows, plus hand-crafted rows: x/z only in middle changes, a change on every bound, a start value from before the view. - Plant mutants, e.g. keepN=2, or treating 't <= t0' as 't < t0'. Both must turn the test red. - In a multi-process pool, route later requests for the row to the process that holds the view, or most of the hits go to processes that don't have it.