v0.13.2

**Fixed.** The live pane was showing 4.6 of the 10 frames a second the capture was already making. It polls the window capture and paused 200 ms between frames, under a comment that knew the engine produces ten a second, asked for five, and reasoned that asking faster "would only show the same frame twice" - which below the source rate is backwards: the other half were captured, held and dropped. Measured on an animating page, same browser, interleaved rounds: 200 ms delivered 4.6 fps to the pane, 60 ms delivers 10.0, which is everything the capture makes.

The lag falls with it. The picture was up to 100 ms old at the capture plus up to 222 ms of waiting; it is now up to 100 plus 82.

60 and not 0 because a frame is one round trip of about 22 ms on the pipe that actions also use. That was the reason to be careful, so it was measured rather than assumed: an action takes 20 ms with the pump idle, 20 ms at this rate, and 18 ms at twice it. The pump is not what an action waits for.

A test now reads the pause out of the page and refuses one that leaves no room for the round trip inside the source period, so 200 cannot come back quietly.

**Still on the table, in the other package.** The capture is asked for 10 fps by `invisible-playwright`, which hardcodes it and gives the caller no say, while the engine takes an `fps` parameter and juggler's own default is 25. Asking for 25 was measured here at 24.0 fps and 629 KB/s against 257, with no effect on action latency. That is a change in that package and belongs to its own release.