Show every frozen slice on the landing page

[DavidBakerEffendi]

Closes the last open gap on #122.

I suggested closing #122 as done. That was wrong — checking its acceptance
criteria against the live page rather than my memory of them:

The homepage should show corpus breadth and confidence together — for
example, "36 published v1 cases, 36 preregistered v2 cases, and N×11
independently re-reviewed legacy cases" — rather than making 36 look like the
entire evidence base.

The live landing page mentioned neither v1, v2, v0.3.0, nor 36. It detailed
the legacy slice and named no other, so 110 read as the whole evidence
base — the same failure the issue was opened against, inverted.

The strip

Above the comparison, all three frozen slices with counts, releases, and total:

Preregistered	36 cases · Prospective v1	v0.2.0
Preregistered	36 cases · Prospective v2	v0.3.0
Retrospective	110 cases · Reviewed legacy core	v0.3.1 · detailed below

Frozen evidence · 182 cases.

The tier is carried by a border colour as well as a word, so the two regimes
stay distinct without reading the label (criterion: "prospectively selected
and retrospectively reviewed results remain visually and textually distinct").
The slice the cards below detail is marked, so the page never implies the
comparison covers all 182.

Counts and releases come from the evidence map like every other number here. A
slice with no published result says "no published result" rather than being
quietly dropped.

The 182 total is a breadth figure, not a denominator — the note states the
slices are never pooled, and what separates the regimes.

Testing

• Fully published evidence map: strip reads 36 / 36 / 110 = 182, all three
  items 122×312, distinct border colours, zero stray margins.
• Checked-in placeholder: whole results view stays in its no-result state and
  the strip does not render.
• astro check clean, links:check 22 routes.

Still open on #122

Not claiming this closes the issue outright — cargo test plus full
corpus/evaluation/promotion validation and rendered mobile QA are listed in
its acceptance criteria and I have only verified desktop widths here.

🤖 Generated with Claude Code

[DavidBakerEffendi]

Mobile QA — passes

Ran the remaining acceptance criterion I flagged as unverified, at 375×812
(iPhone-class viewport) against a fully published evidence map:

• No horizontal overflow. scrollWidth equals clientWidth at 375px, and
  no element inside the breadth strip, the comparison cards, or the short
  answer extends past the viewport edge.
• Cards stack cleanly — one per row at 343px wide, all still a uniform
  190px tall.
• Breadth strip stacks to three full-width items at 343px.
• Nothing truncates. Zero elements among the breakdown labels, version
  tails, and bar labels have scrollWidth > clientWidth — including
  Eclipse JDT LS 1.61.0-202607142124 and 5.3.0 (TypeScript 5.9.3), the two
  longest version strings.

Bars, breakdown rows, and the Both exact / Bifrost only / Reference only
columns all stay aligned at that width.

So desktop and mobile QA are both done for this page. Still outside what I have
verified for #122: the full cargo test plus corpus/evaluation/promotion
validation sweep.