fix(e24): review round 3 — the holes round 2's own fixes left

Round 3 reviewed the round-2 commit across six dimensions. Fifteen findings, five survived
three adversarial refuters each; three died on 2+ refutations (a keyboard-focus claim that
is a property of `ui/Button` at all six of its `loading` call sites, a contract-test
false-pass that needs a deliberate revert plus a self-incriminating comment, and a
MAX_EXCLUDE coupling whose slice is unreachable from the real client).

- `rerolling` was still wrong for a FAILED press. `data === undefined` is true forever for a
  key whose request failed (`retry: false`), so the next unrelated mutation re-disabled the
  reroll button — the same defect round 2 reported, one branch over. `!isFetched` is the
  flag that remembers a key settled; `!isError` would not have worked, because query-core
  resets a data-less query to "pending" for the duration of a refetch, hiding the error
  exactly when it matters.
- The hero fallback used `??`, which cannot tell "this budget's last pick resolved to NO
  hero" from "nothing remembered". So a press that failed after an empty one resurrected the
  card the page had already excluded as seen and just said it had nothing beyond. The tagged
  slot is now authoritative for its own budget.
- `setPage`'s boolean — the input the whole burial rule reads — was asserted by nothing.
  The type fences the SHAPE, so deleting a `return` fails tsc, but swapping the two values
  passed typecheck and all 822 tests. NavigationProvider gets its first render test, on the
  value AND on the effects the early return skips.
- `closeThenNavigate`'s door into `buryUnder` was equally unpinned: reverting that one call
  site to the old unconditional burial left the suite green. It has the mirror case now.
- The comment claiming one rule serves both entry points was overstated. `buryUnder` fails
  OPEN, and `CommandItem.run` is typed `() => void`, so only the palette's bare
  `() => setPage(page)` rows forward the boolean at all. Nothing regressed — that path buried
  unconditionally before — but the prose said more than the code does, so it now says what is
  true and points at the deferred fix. Same for a "the only assertion in the suite" claim
  that the file it cites as precedent also makes.

Every new test mutation-checked red for the right reason, both edges where there are two.
Gate: ruff, ruff format, 3x tsc, eslint (0 errors), prettier, knip, vitest 828, pytest 1005.

frontend/src/components/Home.tsx

@@ -393,10 +393,16 @@ export default function Home() {
   // every mark-watched, bookmark, pin/unpin and shelf move on this page refetches it in the
   // background, and `ui/Button` turns `loading` into `disabled`. So the reroll spun and swallowed
   // clicks after actions the user never associated with it (round 2). A press is outstanding exactly
-  // while THIS key has no answer of its own: the placeholder is still standing in for the previous
-  // press, or — the FIRST press, which has no previous data to stand in — there is nothing at all.
-  // `isPlaceholderData` alone would drop the spinner from exactly that first press.
-  const rerolling = pickQ.isFetching && (pickQ.isPlaceholderData || pickQ.data === undefined);
+  // while THIS key has never settled — which is what `isFetched` means (react-query counts both a
+  // success and an error as settled), and every press mints a fresh seed, so a fresh key.
+  //
+  // Round 3 corrected this: `isPlaceholderData || data === undefined` looked equivalent and was not.
+  // A pick that FAILED leaves its key data-less forever (`retry: false`), so the second disjunct
+  // stayed true and the next unrelated mutation re-disabled the button — the same defect, surviving
+  // in the error branch. Guarding on `!isError` does NOT help either: query-core resets a data-less
+  // query to status "pending" for the duration of a refetch, so the error is invisible exactly when
+  // it matters. `isFetched` is the only flag that remembers.
+  const rerolling = pickQ.isFetching && !pickQ.isFetched;
   // The last pick that actually RESOLVED, tagged with the budget it answered. Every press is a new
   // query key, so a failed one has no data of its own and `keepPreviousData` (pending-only) cannot
   // cover it — without this the hero silently rewound to the card the page loaded with, several
@@ -429,7 +435,15 @@ export default function Home() {
       ? (data?.hero ?? null)
       : pickQ.data !== undefined
         ? pickQ.data.hero
-        : ((lastPick?.budget === budget ? lastPick.hero : null) ?? data?.hero ?? null);
+        : // A ternary, not `??`: the tagged slot is AUTHORITATIVE for its own budget, and "the last
+          // pick for this budget resolved to no hero" is a real answer, not a missing one. Under
+          // `??` the two collapsed, so a failed press after an empty pick resurrected the card the
+          // page loaded with — which it had already excluded as seen and just said it had nothing
+          // beyond (round 3). A mismatched or absent tag still falls through to the loaded hero,
+          // which is what the FIRST press of a budget needs.
+          lastPick?.budget === budget
+          ? lastPick.hero
+          : (data?.hero ?? null);
   // The hero is the top of the resume rail by construction, so leaving it in the rail below prints
   // the same card twice, a hand's width apart. Matched on source+id rather than on the tier alone:
   // a rerolled hero can be a surprise pick that happens to be nothing to do with this rail.