/whatsthat: fix oversized starburst + swap accent to an AA-verified navy against the orange bg

[WilfordGrimley]

Description

Two related /whatsthat visual fixes from the same investigation, both landing on this branch (same page area, owner's call on bundling):

1. Oversized starburst (original commit)

BurstSvg's width: 140% was relative to CardPanel's own rendered width, carried over "verbatim" from the pre-redesign PrintingTagQueue.tsx, where the card column was Col md={4} (33% of the row). The queue redesign widened the card column to Col md={7} (58%) without re-tuning the percentage, so the burst grew large enough to visually collide with the page's own heading and stats text. Reduced to 55%, verified at desktop (1280px) and mobile (390px).

2. Accent color swap (this update)

The #ff4719 orange background stays — owner-ratified as the page's deliberate loud identity. But the site-wide theme accent (#4c9be8, blue) measures 1.16:1 contrast against it — far under WCAG AA's 4.5:1 for text, so links/buttons genuinely drown into the background as reported.

No light tint of any hue clears AA against this orange — even pure white only reaches 3.41:1 (orange's own luminance sits in a mid-range no light color beats by enough margin). Derived a new accent from Superhero's own info/cyan (#5bc0de) by uniform darkening (preserves hue/saturation, only reduces luminance) until AA-for-text clears:

Pair	Contrast	WCAG AA
#12262c (new accent) vs #ff4719 (page bg)	4.60:1	✅ passes 4.5:1 (normal text)
white vs #12262c (button text on new accent)	15.68:1	✅ passes 4.5:1 easily
(reference) old accent #4c9be8 vs #ff4719	1.16:1	❌ fails
(reference) pure white vs #ff4719	3.41:1	❌ still fails

Scope: applied directly on StarburstBackground (the element whose own background is the orange) — specifically not the sibling Footer, which sits on the page's standard dark body background where the original blue accent already has good contrast and must stay unchanged. Covers: links (--bs-link-color-rgb), the "Filter by attribute" toggle (.btn-link), Level 3's "Confirm & continue" (.btn-primary), and the moderator tab switcher's active pill (.nav-pills). Semantic colors (success/danger/warning) and the attribute chips' polarity fills are untouched, per the explicit scope.

Real bug found along the way: overriding --bs-primary/custom properties alone doesn't reach .btn-primary's background — bootswatch's Superhero theme hardcodes a literal background-color on .btn-primary (not var(--bs-btn-bg)), at equal specificity and later in the compiled source order than Bootstrap's own custom-property-driven rule, so it wins regardless of what the custom property resolves to. Fixed by setting background-color/border-color directly (specificity alone wins the cascade, no !important needed) in addition to the custom properties. .btn-link isn't affected by this — bootswatch's hardcoding loop only covers $theme-colors, not the link variant.

Verified zero leakage: computed styles confirmed via live render — /whatsthat's footer links and a completely different page's (/editor) nav link colors are both unchanged. Screenshots (before/after at desktop + mobile, plus the other-page-unchanged proof) attached to the accompanying chat report.

Checklist

• I have updated any related tests for code I modified or added new tests where appropriate.
  • No existing test asserts the burst's exact size or the accent color; nothing to update. Verified manually via live computed-style queries (see report) rather than adding a new automated test, since this is a visual/design judgment call the owner may want to further tune.
• I have manually tested my changes as follows:
  • npx tsc --noEmit: clean except one pre-existing, unrelated error in DisplayPage.tsx (from a concurrent session's PR Proposal H, Step 1: /display route shell behind a feature flag #87, confirmed via git log/git show not caused by either change here).
  • npx jest --runInBand: 32 suites / 345 tests passing.
  • npx eslint + npx prettier --check: clean on all touched files.
  • Live Playwright/MSW render at desktop (1280px) and mobile (390px), reaching Level 3 to verify the primary button, plus a second page to prove zero leakage.
• I have updated any relevant documentation or created new documentation where appropriate.
  • No feature doc covers /whatsthat's color rationale beyond inline code comments (already detailed in this diff); nothing further needed.