🔗 Stamp LATEST_KNOWN_CC from the SoT (#2238)

+ repairs a regression #2229 silently left in the auto-bump workflow

dedicated field, not the frozen `.latest` · stamper-owned, not hand-edited

🐛 The regression #2238 also fixes

#2229 removed the 478-row matrix catalogue. But cc-support-window-bump.yml computed the latest version by grep "minVersion:" cc-version-matrix.ts — now zero matches → ::error::No minVersion entries found. The auto-bump workflow was broken on main and nobody noticed (it only fires on push). #2238 repoints it to the LATEST_KNOWN_CC constant. Simulated: it now reads 2.1.162 instead of erroring.

🧠 Why a dedicated field (not `.latest`)

fieldvaluemeaning
latest2.1.148support-window head (frozen by manual_override)
latest_known (new)2.1.162highest version ork's adoption covers → stamps LATEST_KNOWN_CC

They diverge (2.1.148 vs 2.1.162) while the override freezes the floor. Naively stamping from .latest would have moved the adoption-nudge threshold from >2.1.162 to >2.1.148 — firing constantly. The dedicated field keeps the two concepts separate.

🔄 The wiring

SoT: shared/cc-support.json.latest_known (bump one field)
  ↓ scripts/stamp-cc-support.mjs (now stamps it)
→ cc-version-matrix.ts LATEST_KNOWN_CC
  ↓ read by
→ cc-version-check.ts (the adoption-nudge threshold)

+ cc-support-window-bump.yml bumps latest_known too → fully stamper-owned, no forgotten manual edit.

✅ Verification

Stamper test EXIT 0 — new assertion "LATEST_KNOWN_CC updated (independent of floor)" passes (sets floor=2.1.999, latest_known=2.2.0, proves they stamp independently). actionlint clean. Idempotent: re-stamp at 2.1.162 = no change.

📦 What lands

Closes #2238 (the LATEST_KNOWN_CC follow-up to #2229) — and quietly fixes the auto-bump workflow #2229 had broken.