klipper-linux adapter: Voron 2.4 and generic Klipper hosts on systemd

[LixNix]

What

A new klipper-linux/ adapter for a Klipper printer whose host is a Debian style Linux box with systemd: a Voron 2.4 on MainsailOS, a KIAUH install, a CB1 image. One code base registers two ids, voron-24 ("Voron 2.4") and klipper-generic. Companion to Bespok3d/Bespok3d-desktop#27, which fixes Bespok3d/Bespok3d-desktop#24 (Unknown adapter: voron-24), and to Bespok3d/daemon#6 (daemon 0.14.1).

• Everything runs as the SSH login user under $HOME/bespok3d. Root only through sudo with the account password (fed from a 600 file that the same command removes) for enrolment, deactivate, reactivate and remove. MainsailOS ships no passwordless sudo.
• Runtime privileges are one closed sudoers drop-in, /etc/sudoers.d/bespok3d: start, stop and restart the two Bespok3d units, restart klipper and moonraker, reboot. Full command lines, sudo -n everywhere.
• Two systemd units rendered from templates in the jinni package. The daemon's log is opened by the login user, never by systemd as root.
• Layout discovery reads each unit's EnvironmentFile (klipper.env, moonraker.env) and falls back to the stock home layout; stored as etc/layout.json. Nothing assumes the login is pi.
• Daemon wheels install offline on MainsailOS 2.x (Bookworm, Python 3.11). On 3.0 (Trixie, Python 3.13) enrolment falls back to an online pip install and says why.
• Refused on purpose: web-location plugins (no nginx integration; a root-readable include dir this account could write was a road to root), kernel modules, 32 bit hosts, KIAUH multi-instance layouts.
• The U1 adapter declares its lifecycle steps for the new contract. The stage script, the tag guard and the workflows now handle a second adapter.

Verification

• bash klipper-linux/scripts/check.sh 13/13: ruff, mypy, pytest, tsc, eslint, vitest, shellcheck, size ratchet, em-dash ban.
• End to end on a Debian 12 arm64 QEMU bench laid out like MainsailOS (Klipper on its Linux host MCU, Moonraker, a pi account whose sudo asks for its password), driven by the app's own enrolment, daemon client and lifecycle code: enrol, capabilities, file privacy, deactivate, reactivate with plugin recovery, a second enrolment, removal that leaves klipper and moonraker untouched. Not yet run on real hardware.

[Mauker1]

Should this be referencing the U1?

[Mauker1]

Same thing here, isn't this for the generic linux client?