fix(core): enable supported Debian stable releases

[QinXi-ai]

Summary

Debian 12 and 13 are detected but refused by the supported-host gate. Enable Debian with a known version of at least 12, and refuse missing versions (testing/sid) and older releases. Update the stable-only eligibility documentation without claiming a live Debian validation run.

The routing tests now distinguish eligible Debian from Debian 11/unknown versions. The daemon regression keeps AptUpdate behind eligibility despite its Observer role and keeps Ubuntu-only AddPpa refused on Debian. The action-family test still rejects unrecognised derivatives.

Related Issue

Addresses #238 (eligibility implementation). Live Debian story-suite validation remains pending; I asked about the VM/provider setup in the issue before starting that part.

Validation

• Tests updated: the new Debian eligibility expectation fails on unchanged production code; after the fix, 90 existing tests from the exact distro, action-family and CLI routing source files pass in a standalone Windows rustc --test harness.
• Documentation updated; no Rust test count was added or removed.
• Security impact considered: unknown/old versions fail closed; Ubuntu identity fences remain intact.
• Trust boundary preserved.
• Full Linux workspace/CI validation: pending. cargo nextest run --workspace --locked could not run locally because nextest is absent; this Windows host cannot provide a native Linux daemon/GUI workspace run. The daemon regression is not included in the standalone harness. Evidence counts remain unchanged under CONTRIBUTING.md's documented unavailable-workspace fallback.

Notes for Reviewers

At base 5673d20, the classification constants contain 19 Debian-only, 10 Ubuntu-only and 38 portable/non-canonical-on-Fedora actions; the first and third sets total 57. This classification is not a claim that 57 actions were tested on a real Debian host.

Codex assisted with implementation and validation. No live VM or privileged host actions were run.

[vladimirrott]

Reviewed at 12588cf7. Approving.

You made the open decision rather than inheriting mine, and you wrote down why, which is the part I asked for. Refusing None for testing and sid follows the floor's own security rationale, and you reworded the support-matrix row instead of leaving it claiming something the code no longer means.

What I verified

The guard bites. Reverting the one production line to the old arm, in a container at your head:

$ cargo test --offline --locked -p sysknife-core --lib -- \
    debian_eligibility_requires_a_supported_known_version detect_debian_stable_and_testing
clean:   3 passed
mutated: panicked at distro.rs:1131: assertion `left == right` failed: Some(12)
           left: false, right: true

The exposure question, measured rather than reasoned about. I built the planner catalogue for a Debian hint and an Ubuntu hint and diffed them:

PROBE catalogue total=190 debian=136 ubuntu=160
PROBE debian_catalogue_leak UBUNTU_ONLY = 0 []
PROBE debian_catalogue_leak NON_CANONICAL_ON_DEBIAN_HOST = 0 []
PROBE debian_catalogue_leak NON_CANONICAL_ON_DEBIAN = 0 []
PROBE debian_catalogue_leak FEDORA_ONLY = 0 []
PROBE ubuntu_has_debian_lacks(24) = [AddPpa, RemovePpa, Snap*×9, Netplan*×4,
  CheckPendingReboot, UbuntuReleaseUpgrade, Pro*×5, LivepatchStatus, MultipassList]

Nothing leaks. A Debian 12 planner gets 136 of 190 actions and the 24 it does not get are exactly the Ubuntu-identity set plus the tools Debian does not ship by default. The issue estimated roughly 74 %; the measured catalogue is 71.6 % and the execution fence allows 155 of 190, which is a better number than either of us guessed.

I also confirmed the daemon side moves with it: your for version in [None, Some(11), Some(12), Some(13)] table pins validate_action_platform for AptUpdate to exactly Some(12 | 13) and keeps AddPpa refused on every Debian. That table is the assertion I would have asked for.

One thing to fix before merge

The PR body declares no closing keyword, so merging this leaves #238 open. Add Closes #238 and the CHANGELOG line you already wrote will match what the tracker does.

Merge order

You have four open at once and they conflict only on CHANGELOG.md, one hunk each. I checked every pair. Only #413 moves the test count, so the cheapest order is #412, #414, #415, then #413, and only the last one needs a baseline regeneration. I will do the CHANGELOG resolutions at merge; you do not need to rebase for those.

A follow-up that is not yours

Making Debian eligible surfaced something #384 left behind. Six of the eight Ufw* actions still describe themselves as "Ubuntu only" in the planner catalogue, and all eight are in the Debian catalogue now:

UfwEnable YES  UfwDisable YES  UfwAllow YES  UfwDeny YES
UfwReset YES   UfwLimit YES    UfwStatus no  UfwDeleteRule no

You fixed the two you touched in #415. The other six now tell the model "Ubuntu only" on a Debian host. I will file it.