test(Table): make the status column's colour branches reachable

[IgorShevchik]

Closes #450.

What was wrong

The status column maps three keys to three colours:

const color = ({
  paid: 'air-primary-success',
  failed: 'air-primary-alert',
  refunded: 'air-primary'
})[row.getValue('status') as string]

The fixture carried success, success, processing, success, failed.
Only failed was ever a key. The other four rows resolved to undefined, and
B24Badge fell back to its default colour — so two of the three branches were
unreachable, and the five status cells rendered in two colours where the map
defines three.

The fix

The statuses take the docs example's vocabulary, the same remedy #448 applied
to the dates. TableColumnSortingExample.vue types its rows
'paid' | 'failed' | 'refunded' and uses exactly those — it is where this map
came from; only the statuses were left behind.

id, email and amount are untouched. Those are the upstream fixture and
stay as they are — this aligns the statuses and (in #448) the dates, not the
whole row.

Evidence

Mutation-tested with a baseline, so the difference is measured rather than
asserted. Changing the colour on each branch:

branch	on main	here
paid	74 passed	4 failed
failed	4 failed	4 failed
refunded	74 passed	4 failed

Two of the three were silently invisible; all three now fail.

Four is the ceiling, not a partial score. Exactly two snapshots per project
— renders with columns and renders with meta field on columns — render the
badge at all, so no mutation of a status colour can fail more than four tests.

On the snapshot churn

540 changed lines for a five-value fixture edit looks alarming; almost none of
it is badge markup.

	lines	snapshots
status as plain text	500	50 (25 per project)
status as badge markup	40	4 (2 per project)

The 25 snapshots per project pass data with no columns, so TanStack derives
the columns from Object.keys(data[0]) and the cell is the raw string — every
changed row there is one <td> with a word in it.

What this does not close

One branch is still only half-covered, and the code comment names it.
refunded maps to air-primary, which is src/theme/badge.ts's own default,
so its rendered bytes are indistinguishable from an unmapped status: changing
that colour fails four tests, but deleting the refunded entry fails none.
Closing that needs the fixture's status typed as the union so a dropped key
is a compile error — getValue returns unknown and the as string erases
the key set. Tracked with the rest of that family in #454.

Corrections to the first revision

Five reviewers went over this; four claims in the original write-up did not
survive.

• "the five cells produced two distinct markups rather than three" —
  wrong. There were three distinct markups on both sides (style-filled+
  success, style-filled+processing, style-filled-alert+failed
  before). What went 2 → 3 is the number of colours.
• "the spec and the published example are once again the same data" — too
  broad. Only the statuses and the dates come from the example; id, email
  and amount still diverge, deliberately.
• "the change is confined to the badge markup on the four rows whose status
  changed" — wrong twice. All five rows changed, and 500 of the 540 changed
  lines are not badge markup at all.
• I also meant to claim these snapshots are the only place in the suite pinning
  style-filled-success. They are not — 236 occurrences already exist across
  54 other snapshot files. Dropped.