Scroll when there are more tiles than fit

Shrinking the grid to fit meant a configured tile-width was quietly
ignored the moment enough windows were open — a setting that silently
does not apply is a bug, not a policy. Tiles are now the size the config
asks for and the extra rows scroll.

The layout became a viewport: it reports how many rows fit, elem/tile/
label take a scroll offset and return nothing for tiles above or below
the fold, and hit-testing follows the offset so a click lands on what is
under the cursor rather than what used to be there. Any keyboard move
goes through select(), which scrolls the least that keeps the selection
visible; PgUp/PgDn jump a screen. A scrollbar appears in the right margin
only when there is something to scroll, so it reads as a hint rather than
furniture.

Tiles scrolled out of sight get a null buffer, which unmaps their
subsurface, and the live clock skips them — a long list no longer spends
readback bandwidth on pixels nobody can see. Re-placing the subsurfaces
happens once per dispatch in the event loop rather than inside the key
handler, so holding an arrow key coalesces.

Shrinking survives for one case only: a tile too large for even a single
row or column, where otherwise nothing could be drawn. The old
shrink-to-fit test was rewritten around that, since its premise (twenty
tiles at full size cannot fit) is now answered by scrolling instead.

Verified against the session: 16 tiles at tile-width = 40ppt gives a 2x8
grid with 2 rows visible; three Downs scroll to row 2 and Enter returns
index 6, matching its own list; 82% of the viewport changes across the
scroll; and the scrollbar thumb measures 634px tall at y=24 unscrolled
and y=658 at scroll 2, both what the geometry predicts.

README.md

@@ -95,7 +95,7 @@ chooser_cmd=wl-pick --format portal
 |---|---|
 | `→` `←` / `l` `h` / `Tab` `Shift+Tab` | next / previous tile |
 | `↓` `↑` / `j` `k` | move a row |
-| `Home` `End` | first / last |
+| `Home` `End` / `PgUp` `PgDn` | first / last, or a screen at a time |
 | `Enter` | pick the selection |
 | `Escape` / `q` | cancel |
 | click | pick that tile |
@@ -170,12 +170,18 @@ time it runs. On a mixed setup one file gives 18% of a 1280-wide laptop panel an
 wrong on the other. The overlay is mapped explicitly on that display, at that
 display's scale, so mixed-DPI renders crisply either way.
 
-`tile-width` and `tile-height` are maxima for the thumbnail cell. Give only the
-width and the height follows the display's aspect, which is roughly the shape of
-the windows on it — a 16:9 cell wastes about half its area on a portrait monitor.
-If the grid would outgrow the display, tiles shrink together and keep their
-shape, so thirty windows give small tiles rather than a surface larger than the
-screen.
+`tile-width` and `tile-height` set how big a thumbnail actually is. Give only
+the width and the height follows the display's aspect, which is roughly the shape
+of the windows on it — a 16:9 cell wastes about half its area on a portrait
+monitor.
+
+When there are more rows than the display can show, **the grid scrolls**: the
+tile size you asked for is honoured and a scrollbar appears in the right margin.
+Any move keeps the selection in view, `PgUp`/`PgDn` jump a screen, and tiles
+scrolled out of sight are unmapped — so live capture skips them too, which is
+what stops a long list costing bandwidth for pixels nobody sees. Only a tile too
+large for even one row or column is shrunk, since then nothing could be shown at
+all.
 
 ## Look