feat(list): cap each section and offer the rest

The reader who reported this had two games switched on, twenty-one live
events, and said the list stopped being usable — and every game added doubles
down on that. Each section now shows six rows with an explicit "show all N".

It truncates the view and nothing else. The slice comes off the front of a
list already in the order the reader chose, so the hidden rows keep their
place, stay counted in the header, and stay on the timeline. Expanding is
per-visit state: it is something you do while reading one list, not a
statement about how the app should work.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

AGENTS.md

@@ -433,6 +433,11 @@ to an open page). Four things hold it up:
 - Keep old fixtures when a source changes shape — the old one is the regression test proving the
   parser still handles the previous format. Fixtures are pinned and permanent; `snapshots/` is the
   current page and gets overwritten. Do not conflate them.
+- **Truncating a list is not re-sorting it.** Each section shows `LIST_CAP` rows and offers "show
+  all N". The rows below the cut keep their place in the order, stay counted in the header, and stay
+  on the timeline — so the deadline guarantee two bullets down holds for what is hidden exactly as it
+  does for what is shown. Expanding is per-visit state, not a stored preference: it is something a
+  reader does while reading one list, not a statement about how the app should work.
 - **Which view opens is the reader's answer.** `prefs.view` is asked once on the first run (PRD F8)
   and written by the tabs from then on. It was component state, which meant a reader who preferred
   the timeline was put back on the list by every reload, with nothing to blame but the app