stable-releaselisted

# Stable Release — a named channel on top of rolling `/release` (DOS) `/release` ships a rolling tag (`vX.Y.Z`) whenever DOS lands user-visible change. That tag promises "this commit merged" — it does **not** promise "the substrate was provably trustworthy here." This skill adds a second, less-frequent channel that does make that promise. A stable release is a **promotion of an already-shipped commit**, not a new build. No new version is minted. No new wheel or zip is produced. The gate is read at promote time, frozen into an evidence file, and a second annotated tag (`stable/<codename>`) is pinned on the same commit. > **This is the DOS adaptation of `job`'s stable-release skill.** job gates on > apply-loop hero metrics (silent-failure share, PSV verified-success rate, > funnel-stage regressions) and KEEP-slot baselines from `execution-state.yaml` + > `baselines.yaml`. **None of that exists in DOS** — DOS is a domain-free trust > substrate, not an apply pipeline; it has no runtime funnel, no hero metric, no > baseline ledger. So the gate is re-grounded on the only "known-good" signals > DOS actually has: a green kernel suite, a clean truth syscall, and a soak > window. See "The gate" below. **Trunk is `master`.** The stable tag is pinned on a commit reachable from `master`; the push targets `master`'s remote. **The kernel-vs-tooling boundary.** The gate context script (`scripts/stable_release_context.py`) and this skill are **dev/release tooling that operates ON the pac