"Widely available since" date on feature page uses baseline_low_date instead of baseline_high_date

On https://webstatus.dev/features/avif the page displays "Widely available since 2024-01-25", but the site's own API returns a different date for that transition:

```
GET https://api.webstatus.dev/v1/features/avif
"baseline": { "high_date": "2026-07-25", "low_date": "2024-01-25", "status": "widely" }
```

`2024-01-25` is `baseline_low_date` (when AVIF became *newly* available). `2026-07-25` is `baseline_high_date` (when it became *widely* available, 30 months later, per the Baseline rule). The feature page's "Widely available since" label appears to be sourced from the wrong field — it's showing the newly-available date, not the widely-available date.

This is misleading for anyone tracking Baseline transitions off the rendered page instead of the API — I only caught it because a downstream tool (tracking `baseline_high_date` from the `web-features` npm package) reported the correct 2026-07-25 transition and it didn't match what the site showed.

**Steps to reproduce:**
1. Visit https://webstatus.dev/features/avif
2. Note "Widely available since 2024-01-25"
3. Compare against `GET https://api.webstatus.dev/v1/features/avif` → `high_date: "2026-07-25"`

Start at the feature page https://webstatus.dev/features/avif and compare its rendered “Widely available since” value with GET https://api.webstatus.dev/v1/features/avif, focusing on the baseline low_date and high_date fields. Trace the page’s data source and existing coverage, then verify that the label uses the widely available transition date and that a regression check covers this mismatch.

Written by the indexing model from the issue text.