fix(brain): align Ubuntu-only descriptions with action fences

[QinXi-ai]

Fixes #416.

Planner descriptions claimed Ubuntu exclusivity for Ufw and many other actions that the production execution fence permits elsewhere. Remove the stale claims across the catalogue and assert both directions of the relationship with UBUNTU_ONLY_ACTIONS, including presence of every fenced action in the catalogue. No action availability, execution policy, or public API changes.

Validation:

• The new Rust regression compiled directly from the unchanged production constants and test body fails against the old descriptions (GetAptPins), then passes after the fix.
• cargo fmt --all --check and git diff --check: PASS.
• cargo test -p sysknife-brain --locked ubuntu_only_descriptions_match_execution_fence: BLOCKED on Windows by the existing std::os::unix::net::UnixDatagram import in journal.rs.
• Linux CI on fc53c72 ran the complete workspace: 1,853 passed, 6 skipped. The only red step was the old 1,852 baseline. The official record_test_baseline.py recorder and all three prose files now use that observed count; it is a Linux CI measurement, not an estimated or local Windows count. Evidence: https://github.com/lacs-project/sysknife/actions/runs/34864948327/job/104046325126
• Action reference regenerated from the production constructors and catalogue descriptions.
• Final head 33285c6: Linux workspace passes all 1,853 tests (6 skipped), including the recorded-baseline check; Clippy, rustdoc, frontend, Postgres contract and hygiene gates pass. https://github.com/lacs-project/sysknife/actions/runs/34867797706

CI also surfaced the newly published RUSTSEC-2026-0285 in the inherited lockfile. A separate commit updates rustls to 0.23.45 and its required TLS dependencies; the final security-audit check passes.

Codex assisted with implementation and validation.

[vladimirrott]

Reviewed at 33285c61bae7f87e059d6a2092dbcfc44f7cb696.

Fifty-four action descriptions claimed "Ubuntu only" while the execution fence permitted them elsewhere. AptInstall on Debian 13 is not Ubuntu-only, and the model was being told it was. The fix is the right one and the regression is the right shape.

What matters most here is that your test reads the production constants rather than restating them:

for (name, description) in KNOWN_ACTIONS {
    assert_eq!(
        description.to_ascii_lowercase().contains("ubuntu only"),
        UBUNTU_ONLY_ACTIONS.contains(name),
        "{name}: Ubuntu-only description must match the execution fence"
    );
}
for name in UBUNTU_ONLY_ACTIONS {
    assert!(KNOWN_ACTIONS.iter().any(|(action, _)| action == name), ...);
}

UBUNTU_ONLY_ACTIONS comes from sysknife_core::action_family, so this is a real cross-check between two independent sources, not a parallel copy of the list it is checking. Both directions are covered, and both is_empty assertions in front stop it passing vacuously if either source goes empty. That last detail is the one people skip.

I proved it bites rather than taking the PR body's word for it. Restoring one stripped claim to GetAptPins, in a network-isolated container:

$ sed -i 's|show apt pin priorities (apt-cache policy) — param: package (optional); read-only|...; Ubuntu only; read-only|' \
    crates/sysknife-brain/src/planning_tools/propose_plan.rs
$ cargo test -p sysknife-brain --lib --offline ubuntu_only_descriptions_match_execution_fence
running 1 test
panicked at crates/sysknife-brain/src/planning_tools/propose_plan.rs:732:13:
assertion `left == right` failed: GetAptPins: Ubuntu-only description must match the execution fence
  left: true
 right: false
test result: FAILED. 0 passed; 1 failed

Unmutated, the same command reports running 1 test ... ok. The guard fails when the thing it protects is broken, and it names the offending action.

I checked the fence itself too. UBUNTU_ONLY_ACTIONS has ten entries and every one of them keeps its "Ubuntu only" text; all 54 you stripped live in DEBIAN_ONLY_ACTIONS or one of the NON_CANONICAL_ON_* sets. The realignment is factually correct, not just internally consistent. The Distro column in the generated reference is untouched, which is right, since that derives from action_family and this PR does not change availability.

Test count handled properly: one test added, 1852 to 1853, and all four surfaces moved together.

Your lockfile commit is also doing real work beyond this PR. RUSTSEC-2026-0285 against rustls published today and main at 61b3a878 is red on cargo audit because of it. I confirmed your head clears it:

$ git checkout --detach p413/p426 lockfile state; cargo audit
cargo audit rc=0

Since this is the only one of your four open PRs that does not touch .github/workflows/**, it is the one I can land without a second pair of human eyes on a workflow diff, and landing it takes the advisory off main for everyone else. So this goes first.

Approving, and merging through the gate.

[vladimirrott]

Merged as 4b7b5d5.

The direction you chose is the part worth naming. Ten action names sit in UBUNTU_ONLY_ACTIONS (crates/sysknife-core/src/action_family.rs:142-153), and dozens of catalogue descriptions claimed "Ubuntu only" for actions that fence never covered. Widening the fence to match the prose would also have made the mismatch go away, and it would have changed what the daemon refuses to run on a Debian host. You narrowed the prose instead, and then wrote the test that keeps the two from drifting apart again.

The merge gate ran the proof rather than accepting my summary of it:

$ maintainer-merge verify 426 33285c61bae7f87e059d6a2092dbcfc44f7cb696 'ubuntu_only_descriptions_match_execution_fence' 's/list installed snaps — no params; read-only/list installed snaps — no params; Ubuntu only; read-only/' rust
  rust suite: evidence of 1 executed unit(s), passing unmutated
  applying the mutation and re-running
  receipt recorded for #426 at 33285c61 (observed: clean pass, mutated fail)

The mutation puts one Ubuntu only back onto SnapList, which is not among the ten fenced names, and your guard catches it at rc=101:

test planning_tools::propose_plan::tests::ubuntu_only_descriptions_match_execution_fence ... FAILED

Your lockfile commit cleared the advisory off main in the same merge:

$ grep -A1 '^name = "rustls"$' Cargo.lock
name = "rustls"
version = "0.23.45"
$ cargo audit
rc=0

RUSTSEC-2026-0285 had security-audit red on main and on every open pull request that did not carry your bump. #377 and #401 get a green board out of this, which is worth more than the fence fix on its own.

Two knock-on effects, both mine and neither yours:

• tests/evidence/workspace-tests.json reads 1853 on main now. feat(network): report nftables and firewall backend observations #413 and fix(daemon): declare CHAIN_ROW_COLUMNS once, in store.rs #424 each carry a byte-identical 1852 to 1853 hunk, so git merges them with no conflict and the figure is one short the moment either lands. I regenerate it at merge.
• The Unreleased section records the fence fix and not the rustls upgrade. A dependency bump that closes a published advisory belongs under ### Security, and that line is mine to write.

You are already holding #417, #416, #346 and #239, so I am not putting another issue in front of you.

You have touched the action catalogue, the sudoers grants and the CI gate inside one week, which is most of the surface an operator ever sees. If you run Ubuntu anywhere that matters, a server you patch or a box carrying real traffic, I would like to know how SysKnife reads there. npx sysknife-setup gets it running, and the read-only side (sysknife doctor, sysknife history, sysknife audit verify) changes nothing on the host.