questionFeed: fix subject title overlay, illustration-tile frame, Yes button width

[WilfordGrimley]

Summary

• Fixes What's That: the subject card's title label sits inside the artwork's bounding box, covering its bottom edge #741: the subject card's title (SubjectArtTitle) was absolutely
  positioned inside the artwork's own box, covering its bottom edge. It's
  now a normal-flow sibling below the art — SubjectArt splits into
  SubjectArtImage (owns the art's sizing/aspect-ratio) and the title
  below it, so the title can never share the art's space, at every
  viewport and both Level 1 and Level 2.
• Fixes What's That: illustration and Scryfall artwork render at too small a default size, inside a card-shaped frame that does not match their aspect #746: illustration-group candidate tiles (Scryfall art crops, not
  card-shaped) now render in a new IllustrationArtPlaceholder frame
  sized to the actual crop region's aspect ratio (measured from
  MPCAutofill's ART_CROP_BOX/art_crop_px fixtures), instead of being
  forced through the full card's 63/88 ArtPlaceholder. Ungrouped
  (full-scan) tiles keep the card-ratio frame. CandidateGrid's tile
  size floor/ceiling is also raised (78–116px → 120–190px) since the
  artwork is the subject of the question being asked.
  • Root cause for the frame not reliably honoring either aspect ratio:
    ZoomableThumbnail's img used height: 100% against an
    indeterminate parent, which per the CSS box model falls back to the
    image's own intrinsic ratio and silently overrides the frame's
    declared ratio. ZoomableThumbnail is now position: absolute; inset: 0 so it never participates in that computation — this was a latent
    bug in the existing ArtPlaceholder too, just invisible there
    because real card scans already have a ratio close to 63/88.
• Fixes What's That: the Level 1 Yes button is still visually dominant — block width and accent colour, not font size #740: the Level 1 Yes button drops .block (full width) and
  keeps .primary (colour) — the complaint was about size, not about
  the button being identifiable as the primary action. Dropping the
  class alone wasn't sufficient: ActionStack's default flex
  align-items: stretch was independently forcing the button to the
  row's full width, so its first child now opts out via align-self: flex-start while ActionGrid (needing the full row width for its own
  three siblings) keeps the default.
• SPEC-wtc-rebuild.md: corrects amendment A3, which had concluded the
  title overlay wasn't a defect and attributed the symptom entirely to
  What's That: hover-zoom on card/illustration is clipped by its container frame #705's hover-clipping fix — that conclusion didn't hold, since the
  overlay was unconditional on hover. Supersedes A13 (which kept
  .block). Updates the "subject art title", "candidate grid", and
  "candidate tile" binding-table rows to the new values.
• The reference image's existing container-pinning (A2) is untouched by
  this change — verified it still stays visible while scrolling at every
  viewport tested.

Test plan

• npm test (Jest) — 676/676 passed
• npx playwright test (full suite, chromium) — 347/349 on the first
  parallel run; the 2 failures (DisplayLeftRailFidelity.spec.ts,
  Toasts.spec.ts) both passed standalone on rerun (pre-existing
  parallel-load flakes, unrelated to files touched here)
• npm run build — succeeds
• python3 .github/scripts/coverage_delta.py --base origin/master — clean
• New regression coverage added: title/art non-overlap at Level 1 and
  Level 2 (QuestionFeed.spec.ts), illustration-tile vs ungrouped-tile
  frame aspect ratio (QuestionFeed.spec.ts), Yes button content-width
  vs its "Not sure" sibling (QuestionFeedResponsive.spec.ts)
• Manually verified all three fixes in a real browser (MSW-mocked) at
  390px, 800px, and 1600px, at both Level 1 and Level 2