Eliminate polling latency in BinaryView search generators.

[bpotchik]

Remove 100ms polling latency from BinaryView search QueueGenerator

[psifertex]

claude ID'd a hang if you call next() after emptying the search results. I don't think it's super likely to trigger in practice with well-formed code but it is technically possible now and wasn't before.

┌───────────────────────────────────────────────┬─────────┬────────────┐
│                                               │ with PR │  without   │
├───────────────────────────────────────────────┼─────────┼────────────┤
│ for a, d in bv.search(...) (hit and miss)     │ ok      │ ok         │
├───────────────────────────────────────────────┼─────────┼────────────┤
│ list() / sorted() / any() / zip()             │ ok      │ ok         │
├───────────────────────────────────────────────┼─────────┼────────────┤
│ next(iter(...), None)                         │ ok      │ ok         │
├───────────────────────────────────────────────┼─────────┼────────────┤
│ for ...: break (never exhausted)              │ ok      │ ok         │
├───────────────────────────────────────────────┼─────────┼────────────┤
│ limit=1, take one, then list(g) for leftovers │ ok      │ ok         │
├───────────────────────────────────────────────┼─────────┼────────────┤
│ two for loops over the same generator         │ HANG    │ ok, 210 ms │
├───────────────────────────────────────────────┼─────────┼────────────┤
│ for loop, then a defensive next(g, None)      │ HANG    │ ok, 206 ms │
├───────────────────────────────────────────────┼─────────┼────────────┤
│ two threads draining one generator            │ HANG    │ ok, 105 ms │
└───────────────────────────────────────────────┴─────────┴────────────┘

It does fix the performance issue I was running into!