test(software): add ChairLift system management and helper boundary scenarios

[castrojo]

Summary

Adds behave test scenarios covering ChairLift (io.projectbluefin.chairlift) in the software suite (tests/software/features/chairlift.feature).

Coverage

• ChairLift binary presence and --help CLI surface (--dry-run)
• Privileged helper binaries (chairlift-ublue-helper, chairlift-updex-helper)
• PolicyKit action registrations (io.projectbluefin.chairlift.ublue.*)
• Maintainer configuration file integrity (/usr/share/chairlift/config.yml)
• Desktop application entry presence (io.projectbluefin.chairlift.desktop)
• Privileged helper boundary enforcement and argument rejection (unknown subcommands, image reference injection, restart delay flags)

Closes part of production readiness and shakedown verification for ChairLift.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[hanthor]

Clean mechanically; the open question is whether these can pass today

Test-merged onto main and ran the gate set:

PR806 | snapshot=FRESH | ruff='All checks passed!' | pytest: 1571 passed

No conflicts, snapshot correctly regenerated, no new step definitions needed (everything reuses Run SSH command: / SSH command output contains). Small and well-scoped.

Two things to confirm before it lands

1. All 8 scenarios are unconditionally active. Every one is tagged @software @chairlift with no @pending / @requires_* gate, and the snapshot delta counts them as active coverage. If io.projectbluefin.chairlift is not installed on the image the software lane runs against, the first scenario fails on test -x /usr/bin/chairlift and the lane goes red on an absence, not a regression. Has this been run against a live image? If ChairLift is not shipped everywhere the software suite runs, these want a gate the way @requires_bctl / @requires_cached_image are used elsewhere in the repo.

2. The boundary scenarios assert exact error strings.

* Run SSH command: "chairlift-ublue-helper unknown-subcommand 2>&1 || true"
* SSH command output contains "unknown command"
* Run SSH command: "chairlift-ublue-helper channel-switch 'ghcr.io/evil/image:latest' 2>&1 || true"
* SSH command output contains "usage: chairlift-ublue-helper channel-switch"

The direction is right — asserting the helper rejects an injected image ref rather than accepting it. But "unknown command" and "usage: chairlift-ublue-helper channel-switch" are exact lowercase substrings of the helper's stderr. If those came from reading the ChairLift source, a pointer to the file/line in the description would make this reviewable; if they were inferred, they are the kind of assertion that fails on a harmless wording change. Matching on the exit code plus a looser marker would be more durable.

Also worth noting: the 2>&1 || true means a helper that segfaults rather than printing usage produces empty output and the step fails — which is fine — but a helper that is missing entirely fails here too, duplicating scenario 3. Not a problem, just redundancy.

Nothing here blocks merge on its own; I would want an answer on (1) before it goes into the queue.

---

Generated by Claude Code