Default error colour fails AA in dark mode (white on #F5394F = 3.76:1)

The default `--color-on-error` / `--color-error` pair is **3.76:1** in dark mode — white `#FFFFFF` on `#F5394F`. Below AA (4.5:1) for normal text.

It is not theoretical. Any theme that leaves the status colours alone renders a destructive button that way; measured off the real DOM (`core-button--destructive`, dark, `getComputedStyle`):

```
rgb(245, 57, 79) / rgb(255, 255, 255) → 3.76 ("Delete")
```

Light mode is fine at 4.70:1, and the shipped themes are fine because they all happen to retone error. It is the default that fails, so it hits exactly the themes that trusted the defaults: six of nine independently written themes in a recent authoring experiment shipped it.

`--color-on-accent` / `--color-accent` is in the same position at **3.11:1** in dark (`#FFFFFF` on `#2694FE`), though a primary button is arguably large-text/UI-component territory (≥3:1) where error text usually is not.

Both are visible to `expandColorScale`'s own machinery — the generated palettes are held to 4.5:1 by tone spacing, and the status colours are the documented exception that falls through to `colorDefaults`. Two candidates:

1. Darken the dark-mode error (a tone step or two) until white clears 4.5:1, and check the same for accent.
2. Bring the status pairs inside the generator's guarantee instead of exempting them, so `on-*` is derived from whatever `*` ends up being.

I would do (1) now and consider (2) with #5014, which is the general version of this — a hand-authored side of a pair losing the guarantee silently. A contrast assertion over the default token pairs would keep both closed.