feat: "show events that haven't started" governs both views

It was the board's alone, sitting between two app-wide filters and
carrying a line of small print to explain why it was different. It is the
same events answering the same question in either view, so it is now one
switch: the board plots them, and the checklist keeps its "Not started
yet" section.

That means the section is off by default, which is a visible change for
every existing reader — deliberate, and the same argument the board makes.
This app answers what expires next; on fourteen lanes the queued patches
are more rows than the thing they came for.

`timelineUpcoming` becomes `showUpcoming`, because the old name would now
be false, and `adoptRenamed` carries a stored answer across on load.
Nothing would be lost by dropping it — `prefs` is one blob under one key,
not a key space — but a reader who had switched the future on would find
it off with no explanation, and they should not have to say a thing
twice. A stored new name always wins, so it cannot overwrite a fresher
answer with a stale one.

Gating the section alone would have opened a hole: nothing running and
everything held back rendered an empty column, because the "nothing to
show" line keyed off there being no rows at all rather than none listed.
It now counts what is held back and names the switch, as the board does.

The split pills stay the board's: the checklist gives these a section
with a heading either way, so there is nothing there to mix them into.

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

test/prefs.test.ts

@@ -1,5 +1,5 @@
 import { describe, expect, test } from "bun:test";
-import { adoptNewLanes } from "../src/client/state/usePrefs.ts";
+import { adoptNewLanes, adoptRenamed } from "../src/client/state/usePrefs.ts";
 import type { LaneId } from "../src/shared/custom.ts";
 
 /**
@@ -66,3 +66,43 @@ describe("adoptNewLanes", () => {
     expect(patch?.hiddenGames).toEqual(["hsr", "fgo"]);
   });
 });
+
+/**
+ * A preference that changed its name.
+ *
+ * `timelineUpcoming` governed the board alone; `showUpcoming` governs the
+ * checklist too. Nothing is lost by dropping the old name — `prefs` is one blob
+ * under one key — but a reader who had switched the future on would find it off
+ * again with no explanation, which is the same failure as forgetting their view.
+ */
+describe("adoptRenamed", () => {
+  test("a reader's old answer is carried across", () => {
+    expect(adoptRenamed({ timelineUpcoming: true })).toEqual({
+      showUpcoming: true,
+    });
+    // Both directions: having said no is also an answer.
+    expect(adoptRenamed({ timelineUpcoming: false })).toEqual({
+      showUpcoming: false,
+    });
+  });
+
+  test("the old name never overwrites a fresher one", () => {
+    // Once written back under the new name, the leftover must not undo it —
+    // otherwise the setting would spring back on every load.
+    expect(
+      adoptRenamed({ timelineUpcoming: true, showUpcoming: false }),
+    ).toEqual({ showUpcoming: false });
+  });
+
+  test("it is dropped rather than carried into the stored object", () => {
+    // Kept, it would be written straight back and outlive the migration.
+    expect(
+      Object.keys(adoptRenamed({ timelineUpcoming: true, sort: "doing" })),
+    ).toEqual(["sort", "showUpcoming"]);
+  });
+
+  test("a reader with neither is left alone", () => {
+    expect(adoptRenamed({ sort: "doing" })).toEqual({ sort: "doing" });
+    expect(adoptRenamed({})).toEqual({});
+  });
+});