Define a status taxonomy for renderers (parallel to spec version taxonomy from #1240)

Follow-up from #1302 (review thread between @ditman and me).

#1240 settled on a clear taxonomy for **specification versions**: `draft` / `candidate` / `final` / `deprecated`. We don't have an equivalent for **renderers**, and the [Roadmap](https://github.com/google/A2UI/blob/main/docs/roadmap.md) currently uses an informal mix:

- ✅ Stable — Web Core Lib, Lit, Angular, Flutter, Markdown, React
- 📋 Planned — Jetpack Compose, SwiftUI
- 💡 Proposed — Vue, Svelte, ShadCN

@ditman raised the question: should we replace `Stable` with `Available` or similar? I pushed back on `Available` (loses the maturity signal — a freshly-shipped renderer is "available" the moment it's published, indistinguishable from one hardened by users for a year). But `Stable` is also imperfect pre-1.0.

### Options to consider

1. **Mirror the spec taxonomy** — `draft` / `candidate` / `stable` / `deprecated`. Couples renderer maturity to the spec version it targets. Conceptually clean; reuses vocabulary contributors already learned.
2. **OSS-standard ladder** — `alpha` / `beta` / `stable` / `deprecated`. Most renderers would currently be `beta` since we're pre-1.0. Honest but might feel like a downgrade.
3. **Available / Planned / Proposed** (@ditman's suggestion) — Simple, flat, no maturity signal.
4. **Hybrid** — Use the spec taxonomy for renderer↔spec compatibility (per spec version), and a separate maturity label per renderer overall.

### Things to decide

- Single status per renderer, or status per (renderer × spec version) cell? (The reference table is already 2D today.)
- Do we want a "recommended" / "latest" signal, or is that implied by the table ordering?
- Should the labels live in `docs/glossary.md` next to the spec version taxonomy?

cc @polina-c @ditman @jacobsimionato