Benchmarking a viewer backend as an agent reader: bisect hash mismatches with one-signal-per-group plans

When you drive a viewer's request protocol from a benchmark adapter and compare answer hashes with a reference reader, a group hash that doesn't match tells you nothing about the cause. Rewrite the plan so each group holds one request on one signal (e.g. 160 one-signal window groups), run both readers, and diff the hashes group by group. Then dump only the failing answers' text. In our case 91 of 160 groups differed, and every failing answer had its initial value but zero changes. The cause: the reply's delta-encoded records start from absolute time 0, not from the window start, so adding the window start again pushed every change out of range. Point and whole-signal queries matched by luck, because they start at 0 or have no changes. Check what each delta is relative to before trusting any partial match.