fix(question-feed): direct-access Yes/No chips, narrowing after no-match, art-crop gap documented

[WilfordGrimley]

Summary

Three owner-reported question-feed interaction defects (frontend-only;
question_feed.py/reason_tags.py and every other Python file are out of
scope here, handled by a separate concurrent worker):

1. Several clicks before a vote counts. Confirmed root cause by reading
   nextChipState and the level3/candidate render blocks: attribute chips
   (attributeChipRender.tsx, shared verbatim by the question feed's ring
   and the display page's rail — a header comment enforces this) required a
   tap sequence (untouched -> positive -> negative -> untouched) to
   reach "No", and an implied-negative exclusion-group sibling rendered
   dimmed at opacity 0.45 while having cast no vote of its own — a voter
   reading that dimming as "I already said no" was looking at UI that
   disagreed with the data. Each chip is now a labelled Yes/No button pair:
   any of the three meaningful answers (yes / no / no opinion) is reachable
   in exactly one tap from any prior state, and the button reflecting the
   voter's own explicit answer is now visually independent of the
   fluctuating community-plus-machine lean fill (which is what let a
   just-cast vote appear to "not have registered" once the server's real
   weighted polarity replaced the optimistic one). Retraction (tapping the
   already-active button back to untouched, casting RETRACT_POLARITY) is
   unchanged — only how many taps it takes to reach any of the three states
   changed.

2. Bringing the narrowing selector in after a no-match. On the
   NoMatchReasonStrip's not-official-printing axis (altered-frame /
   upscaled / no-collector-line / non-english — the artwork is genuine,
   only which printing is still in question), choosing a reason now returns
   to the same item's Level 2 candidate grid with the attribute-chip filter
   panel already expanded, instead of skipping straight to the next item.
   This reuses the funnel's own existing chip-narrowing filter
   (filterCandidatesByChipStates + the shared renderAttributeChip)
   rather than forking in the unified editor's SelectVersionResults.tsx
   selector pieces, and candidate selection still goes through the
   unchanged, already-supported selectCandidate path — no new printing
   assertion is submitted. On the not-official-art axis (custom-art /
   ai-art / external-ip), the artwork itself isn't from any official card,
   so there's nothing to narrow towards — that axis still advances straight
   through, unchanged.

3. Printings shown where an art crop would do. Confirmed by reading the
   candidate-tile render and schema_types.ts: illustration-clustered
   tiles vote at illustration granularity (selectIllustrationGroup ->
   /2/submitIllustrationVote/) but still render each candidate's own
   mediumThumbnailUrl (a per-printing scan), because no per-candidate or
   per-illustration art-crop URL exists on the questionFeed payload —
   QuestionFeedItem.scryfallIllustrationUrl is a single, item-level field
   consumed only by the unrelated artist question type's subject-card
   re-frame. Documented as a known gap in
   docs/features/printing-tags.md, with what a backend change would need
   to add to make this fixable. No backend change was made or attempted —
   out of scope for this PR.

Test plan

• attributeChips.test.ts — pass, individually and combined
• AttributeChipPanel.test.tsx — pass, individually and combined
  (rewritten: the old "cycles through 3 states" test is now "reaches
  each state in exactly one tap, no cycle")
• QuestionFeed.test.tsx — pass, individually and combined
• NoMatchReasonStrip.spec.ts (Playwright e2e, real browser + mocked
  network) — pass; two new cases added (not-official-printing returns
  to the grid, not-official-art still advances) and the existing
  "OTHER group" case updated to match the new not-official-printing
  routing
• QuestionFeed.spec.ts + QuestionFeedResponsive.spec.ts (Playwright
  e2e) — pass, including the 44px tap-target-floor check against the
  redesigned chip
• npx tsc --noEmit — clean
• npx eslint on every touched file — 0 errors (pre-existing
  no-img-element warnings only, unrelated to this change)
• Full npm test — same 22 pre-existing failures as before this
  branch (comparison.test.ts's Set.prototype.symmetricDifference,
  unavailable on this sandbox's Node 20 runtime; untouched by this PR),
  no new failures

Task-end checks (CLAUDE.md)

• Docs convention (edit in place, no dated section): docs/features/ printing-tags.md's "Known gaps" section updated in place with the
  art-crop finding; no new dated section appended.
• Wiki maintenance: no user- or admin-visible surface changed in a way the
  wiki documents beyond what printing-tags.md already covers — no wiki
  edit needed.
• Extractable-primitives ledger: no primitive extracted or destroyed.
• Constant renames: none.
• Push policy: pushed to a named branch in a dedicated worktree, PR opened
  against master, not merged — merges are the owner's alone.