Per systemd's desktop environment recommendations [1], transient .service
units are preferred over .scope units when launching applications. This
ensures the systemd user session is the direct parent of launched processes.
The previous approach (desktop-systemd-scope) spawned processes via
double-fork (orphaning them to PID 1), then moved them into a scope.
Security tools like 1Password that verify parent process lineage rejected
these processes because their ancestor chain led to PID 1 rather than
systemd --user.
This commit adds a new 'desktop-systemd-service' feature that uses
StartTransientUnit with ExecStart to let systemd spawn the process
directly, giving launched applications a proper parent lineage.
Feature behavior:
- desktop-systemd-service only: Uses transient .service units
- desktop-systemd-scope only: Uses transient .scope units (existing behavior)
- Both enabled: Tries .service first, falls back to .scope, then double-fork
- Neither enabled: Uses double-fork directly
Also fixes typo: SystemdManger -> SystemdManager
[1] https://systemd.io/DESKTOP_ENVIRONMENTS/
2af4cff958