feat(prefs): a game we add arrives switched off

Adding a source is our decision, not the reader's. Eleven lanes became
fourteen this week, and for someone who plays two that is not a feature
arriving — it is their calendar filling with events they will never open,
which is the thing the first-run picker exists to prevent.

`knownGames` records every lane a reader has been offered; a lane missing from
it is new to them, so it is recorded and hidden on sight. The games chips in
settings list every lane, on or off, which is where they take one up.

The case that had to be right is the reader who installed before any of this
existed: they have no `knownGames` at all, and reading that as "has been
offered nothing" would switch off every game they already read. Absent means
unrecorded — the first pass records what is already on their screen and
changes nothing else. Lanes they invented are recorded but never hidden;
typing a game in is asking for it.

The decision is a pure function so this is provable rather than watched for.
One real cost, stated in the PRD rather than hidden: a reader whose game
finally arrives is not told, which makes the colophon roadmap matter more.

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

docs/PRD.md

@@ -187,8 +187,22 @@ Before any events are shown, the reader picks which games they play, and how the
 them. A calendar full of games they
 don't play is worse than an empty one — it buries the thing they came for. Nothing is preselected
 and the button stays disabled until something is chosen; guessing on their behalf and hoping they
-notice is worse than asking. The choice is stored as *hidden* games, the inverse, so a game added
-later appears by default rather than staying invisible forever.
+notice is worse than asking. The choice is stored as *hidden* games, the inverse — which is a storage
+shape, not a policy: what happens to a game added later is decided separately, below.
+
+**A game added later arrives switched off.** Adding a source is our decision, not the reader's, and
+someone who plays two games did not ask for the other twelve; a calendar that fills itself up is the
+thing this screen exists to prevent. `prefs.knownGames` records every lane a reader has been offered,
+and a lane missing from it is recorded and hidden on sight. The games chips in settings list every
+lane, on or off, which is where they take a new one up — and the cost of this is real and worth
+stating: a reader whose game finally arrives is not told, so the roadmap line in the colophon
+(`docs/FEEDBACK.md` P1c) matters more, not less.
+
+An absent `knownGames` means *unrecorded*, never *offered nothing* — every reader who installed
+before it existed is in that state, and reading it the other way would switch off every game they
+already read. The first pass records what is already on their screen and changes nothing else.
+Lanes the reader invented (`mygame:`) are recorded but never hidden: typing a game in is asking for
+it.
 
 The view question (F2) sits under it, with each option drawn rather than only described — the words
 "list" and "timeline" mean nothing until you have seen this app's version of them. Unlike the games,