logan
ddd04623f7
`album-dropdown`'s "can be scrolled" failed twice over two sessions with `Expected 80, Received 10`, both times on a branch that could not have caused it. #133 strengthened the guard from "scrollable at all" to "has the range this assertion needs", which was necessary and cannot be sufficient: the guard and the write are separate round trips, so the page re-lays-out between them. Measured every frame across the resize, three runs: the range goes 0 → **88** at 1ms → 330 settled by 8-14ms. 88 satisfies a guard asking for 80 while the grid is still a pass from done, so the guard is capable of passing on a layout that is about to move. Under full-suite load the transient is worse — the observed failures read 10 — which is why this shows up on the second run of a suite and not in ten consecutive runs of the file alone (0/10 before the change and after it; isolation is not where this lives). So the probe sets `scrollTop` and returns what it reads back, in one page-side call, and the poll retries that. The assertion is now about what the grid did rather than about what it was ready to do, and there is no window between deciding and doing for anything to happen in. #133's own last line asked for the other viewport-shrinking specs to be swept for the same shape. One had it: `layout-overflow`'s sidebar probe already fused its scroll and its measurement into one evaluate but ran it once, so it read whatever the sidebar happened to be doing after the resize. It is polled now — safe to repeat, because scrolling to the bottom twice is scrolling to the bottom. Closes #151