fix(ipc) step over a run of lost events instead of one per poll()

[TheophileDiot]

Fixes #130.

poll() advances one index per call when an event never arrives, so a run of lost events costs the full timeout on every call. broadcast() consumes its index at incr() before set() stores anything, so the hole is left both by an evicted event and by a set() that returned no memory, and neither can be filled afterwards.

When the retry loop times out this now walks forward to the next index the shm still holds and resumes just before it, capped at MAX_HOLE_SCAN so a single call cannot scan an unbounded range. When the cap is reached it resumes where the scan stopped, so a longer run costs one more poll() per chunk rather than the events sitting behind it.

poll() still returns nil, "timeout", so the caller learns events were lost exactly as before, and TEST 12, 13 and 15 are untouched. The cold worker path from #87 is untouched too, since it fires at self.idx == 0 before this code is reached.

TEST 19 covers the walk: five events are deleted with a sixth left in place, and the first poll() has to land on index 5 rather than index 1.

We're carrying this as a patch on 2.7.0 in BunkerWeb. I couldn't run prove locally, so the suite needs a CI run.