Put the archive browser back on dash's metrics

[Babissimo]

data-explorer takes dash's palette verbatim (and, since #383, the map's dark
one) but never took its spacing. It had drifted a step denser everywhere — a
14px base, 7/14 buttons, 26px stat values, 16px card padding, 10px column
heads — so two sites sharing a palette read at different sizes. None of the
drift looks deliberate.

Sizes and padding now come from dashboard/src/App.css alongside the colours,
and the page rhythm is one number rather than a mix of 20 and 24.

Two places the parity could not be taken literally:

• Dropping the 14px base hands loose in-flow text the browser's 16px. That is
  right for the empty state (dash's is 16px too) and wrong for the filter-bar
  separators and the drawer's loading line, so those containers carry an
  explicit 13px.
• An 11px column head no longer fits the coverage cell in the narrow grid —
  measured at 139px for the header and 134px for the widest cell — so that
  column goes from 130px to 145px.

.card keeps overflow:visible against dash's hidden, because the node
dropdown has to escape the card, and now carries a comment saying so.

Verification

• backend/.venv/bin/pre-commit run --all-files — all five hooks pass. No hook
  covers CSS, so it proves nothing about this change beyond leaving the Python
  gate untouched.
• Rendered before and after from two local static servers at 1280px, 1000px and
  375px. No horizontal overflow at any width; the coverage cell and column head
  stay on one line at both breakpoints; the topbar's wrap at phone width is
  unchanged (it wraps on main too).
• Backendless, so the file rows were measured by injecting a representative row
  rather than by listing real files.

🤖 Generated with Claude Code

[claude]

Claude finished @Babissimo's task in 2m 12s —— View job

---

Review: Put the archive browser back on dash's metrics (#386)

• Gather context (PR diff, description, CLAUDE.md)
• Read changed file (data-explorer/app.css)
• Compare against dashboard/src/App.css for the claimed parity
• Check verification claims (breakpoints, coverage cell width, .card overflow)
• Post review feedback

Summary: This is a clean, well-scoped CSS-only change. I checked every parity claim in the PR body against dashboard/src/App.css line by line and they all hold:

• body has no explicit font-size in dash either (falls through to the UA 16px) — matches dropping the 14px base.
• .stat-card padding 20px, .stat-value 28px, .card-header/.card-body padding, .btn 8px 16px + transition:all .15s, .page-header{margin-bottom:24px}, .stats-grid{minmax(220px,1fr); margin-bottom:24px} — all byte-for-byte identical to dash's values.
• a:hover/.topnav a:hover/button hovers dropping text-decoration:underline matches dash's hover behavior (color-only, no underline).
• The three "can't take parity literally" exceptions check out against actual markup: .frow and .near wrap genuinely unstyled inline text nodes (the →/± separators in index.html:90,107,116), and the drawer's Downloading… line (app.js:927) has no own font-size, so it needed the explicit 13px call-out. .empty-state has no font-size in dash either, so leaving it at the inherited 16px is correct.
• .card{overflow:visible} is intentionally kept off dash's overflow:hidden and now carries an explanatory comment (app.css:98) — matches the stated reason (node dropdown escaping the card).
• The narrow-grid column bump (130px → 145px) lines up with the .colhead font bump from 10px → 11px in the same diff, which is a plausible cause of needing more width for the "Coverage" header text.

Minor, non-blocking observation: the new .frow{font-size:13px} and .near{font-size:13px} rules also apply to two other .frow usages not mentioned in the PR body — the card-header rows in "Availability" (index.html:151) and "Results" (index.html:170), which mix .btn and .muted.tl-range children. This is harmless: .btn (13px) and .tl-range (12px, applied directly to the span) both already carry explicit sizes that win over the inherited value, so nothing visibly changes there — just flagging that the rule's reach is broader than the two cases called out in the description.

No correctness issues found. contracts/nodes-v1.openapi.yaml is not implicated (no /v1/nodes routes or node_config.py touched), so the generated-contract gate in CLAUDE.md doesn't apply here.