Proposal H, Step 2 PR 2b: requested-printing badge + Confirm affordance

[WilfordGrimley]

Description

Instrument parity, PR 2b of the Step 2 sequence for docs/proposals/proposal-h-unified-display-page.md
(behind NEXT_PUBLIC_UNIFIED_DISPLAY_ENABLED; PR 2a/#96 already merged). Wires the rail's
always-visible status header to two real instruments per the design doc's §2/§5:

Requested-printing badge, full degraded-state treatment. EditorSearchResponse.degradedQueries
(schema_types.ts) was already returned by the backend but discarded on the frontend before this PR

• APIEditorSearch only ever returned content.results. This PR:
• Changes APIEditorSearch/APIEditorSearchLegacy (api.ts) to return {results, degradedQueries}.
  The legacy (2/editorSearch/) endpoint predates this field entirely, so it always reports [].
• searchResultsSlice.ts: doSearch() accumulates degradedQueryHashKeys across paginated remote
  requests (client-side/local-folder search never reports degraded queries - only the remote backend
  can retry a printing filter unfiltered); the fetchSearchResults.fulfilled reducer merges new
  hash keys without duplicating; clearSearchResults resets them alongside searchResults.
• New selectIsSearchQueryDegraded selector: true only for a query that both carries a printing
  filter (expansionCode) and whose hash key is in degradedQueryHashKeys.
• DisplayPage.tsx's RailHeader: the badge switches from bg-secondary to a bg-warning text-dark degraded style (plus a warning icon and explanatory title) when
  selectIsSearchQueryDegraded is true. Bootswatch's Superhero theme is known to hardcode some
  component colors past the CSS-variable layer (see PR /whatsthat: fix oversized starburst + swap accent to an AA-verified navy against the orange bg #91's own theming caveat), so the new
  Playwright test reads the badge's actual getComputedStyle().backgroundColor, not just its
  class name, to confirm the degraded state really renders as a distinct, visibly-warm color.

Confirm? affordance in the rail's header. Mounts the real DeckbuilderConfirmAffordance -
the exact same component CardSlot.tsx already mounts in the classic editor, not a fork. The only
adapted prop is onOpenGridSelector: the rail has no modal to open, so N expands (or keeps
expanded, if already open) the Choose Image accordion section instead, per the design doc's §4.3/
§4.4 ("focus, if already open").

Checklist

• I have installed pre-commit and installed the hooks with pre-commit install before creating any commits.
• I have updated any related tests for code I modified or added new tests where appropriate.
• I have manually tested my changes as follows:
  • DisplayPage.spec.ts (13 tests, incl. 4 new: plain-badge, degraded-badge with computed-style
    verification, Confirm affordance YES vote, Confirm affordance NO expanding Choose Image).
  • searchResultsSlice.test.ts (new degradedQueryHashKeys reducer tests + selectIsSearchQueryDegraded
    selector test), full existing mergeSearchResults coverage unaffected.
  • CardSlot.spec.ts/DeckbuilderConfirmAffordance.spec.ts (individually/filtered - this sandbox
    hit intermittent Playwright test-collection flakiness on full-file runs today, reproducing even
    on completely untouched spec files like GridSelectorModal.spec.ts; every test verified
    individually/in filtered subsets passed cleanly, confirming this is sandbox flakiness, not a
    regression from this change).
  • npx tsc --noEmit clean.
  • npx jest - 359 tests passing, 0 failures.
  • NEXT_PUBLIC_UNIFIED_DISPLAY_ENABLED=true npx next build - clean production build with the
    flag on (the standing verification bar from PR Fix production build: RailProps.cardDocumentsByIdentifier needs | undefined #90's build-failure lesson).
• I have updated any relevant documentation or created new documentation where appropriate.

Per the Step 2 instructions: zero changes to the classic editor's/DeckbuilderConfirmAffordance's
own behavior (verified above - same component, same gating logic, only the mount-site prop differs).

---

Generated by Claude Code