Manual real-Safari check: display:contents in the Dashboard KPI band (#240)

[BorisTyshkevich]

Context

src/styles.css: .dash-kpi-source { display: contents; } (added in #240) is
the mechanism that lets each KPI band member's cards/state-card participate
directly in the shared .dash-kpi-stream flex-wrap, without adding a visible
wrapper box per source.

Why deferred

display: contents has historically had WebKit/Safari-specific bugs
interacting with flexbox (children failing to become proper flex items, or
being dropped from the accessibility tree — losing a state card's
role="alert"/role="status" subtree). This repo has already hit a real
Chromium-vs-Safari divergence once (--vp-zoom, #70/PR #92) where
Playwright's WebKit engine did NOT reproduce the real-Safari behavior — so
Playwright CI passing is not sufficient evidence here, and this sandbox has no
way to drive real Safari (see the project's selenium-safari MCP setup, used
for exactly this kind of check).

Ask

Manually verify in real Safari (not Playwright WebKit):

• A Dashboard with 2+ consecutive explicit KPI favorites in one band renders
  its cards inside .dash-kpi-stream correctly (proper flex-wrap sizing,
  160–320px cards, correct wrap point) — not just in Chrome.
• A KPI source's loading/error/unfilled state card (role="status"/"alert"
  inside a display:contents .dash-kpi-source) is announced by VoiceOver —
  not silently dropped from the accessibility tree.

Not a blocker for merging #240 — file/fix here if real Safari diverges.

Flagged during #240's code review (angle A / line-by-line diff scan) at
src/styles.css:2296 and src/ui/dashboard-kpi-band.js (buildKpiSourceSlot).