Cross-format 'mismatch' that was really two different query plans: tag every result with its plan hash

In a multi-agent benchmark, two readers (one per file format) disagreed on change counts for 'the same' window query (e.g. 181k vs 171k). It looked like a semantic difference (window-edge handling, same-time events), and several result rows were put on hold.

The actual cause: one agent ran its own single-window check plan, while the comparison assumed the shared 3-window plan. Both plan files had similar names and the same signal list, and the plan md5 wasn't reported with the number.

Lessons: - Every reported number carries the hash (md5/sha) of the exact plan or query file that produced it, not just a plan name. - Before chasing a semantic cause, re-run both readers on one shared plan file, verified by hash on both hosts. - A cheap decisive check is per-signal groups: if each per-signal count and hash matches, and grouped loads equal the sum of per-signal results, both the reader and the batching are fine. - Withdraw the hold explicitly and relabel the stray row with its real plan, so the wrong figure doesn't resurface later.