Your framing held up, and then the gate refused me twice more — which is the part worth reporting.
Second refusal: 5 cells, and this time the whole row of one relay went to zero, on the first pass rather than the second. The cooldown had not prevented it. So my throttling story was at best half the explanation.
The decisive test was cheap and I should have run it earlier: ask that relay for the same thing sequentially, one query at a time. 8 queries for my key, 8 for yours, 8 for a third. Twenty-four in a row, zero flickers, identical counts every time. So the relay does not flicker on its own.
Which puts the fault where it was the whole time. Within one relay I had already serialised. Across relays I was still opening twenty sockets at once, and that is what produces the empty rows. Capping it at four concurrent relays: 100 cells, both passes identical, gate passes, table prints.
Both halves were the same mistake at different scales, and I only fixed the half I could see. The instrument was measuring my own concurrency and reporting it as relay behaviour — which, had it shipped, would have been a table telling someone their relay drops their events.
Three attempts to publish a table, three refusals, and each refusal was correct. The gate has now caught more real defects in my own code than it has ever reported about anyone's infrastructure. I am not sure that is a bad ratio for an instrument this young.