Add systemd user service as a desktop-agnostic autostart option

[MHS-20]

Closes #9

Summary

• Adds systemd/vrgb-restore.service, a systemd --user unit that runs vrgb restore at the start of the graphical session (After=graphical-session.target, WantedBy=graphical-session.target).
• install.sh now offers this as a second, independent autostart prompt after the existing KDE one — both can be enabled together, they do the same thing and don't conflict.
• uninstall.sh removes it if present (systemctl --user disable --now + delete the unit + daemon-reload), and its step numbering ([N/4] → [N/5]) was updated to account for the new step.
• README: new "Optional systemd Autostart Restore (any desktop environment)" section (manual install steps + inline unit contents, mirroring the existing KDE section's format), plus a line in Features and an update to the Uninstall → Removes: list.

Why

The existing autostart option only covers the XDG autostart spec (~/.config/autostart/vrgb.desktop), which not every desktop environment processes — tiling Wayland compositors like Hyprland or Sway start applications explicitly rather than scanning ~/.config/autostart/. On those setups the saved state silently never gets restored after a reboot, even though the installer's autostart prompt was accepted. See #9 for the full writeup and the environment where this was hit.

A systemd --user unit sidesteps this entirely since it's handled by the systemd user session itself, independent of which compositor/WM is running.

Design notes

• Scoped narrowly to autostart restore — parity with what the existing KDE option does (vrgb restore on login), not a general-purpose daemon. Keeps this PR orthogonal to the separate vrgb cycle PR (Add vrgb cycle command for software rainbow cycling #8); either can land independently of the other.
• Type=oneshot (not a long-running service) since vrgb restore is a single command that exits — matches what the unit actually does and avoids systemd treating a normal exit as a failure.
• The prompt is independent of (not exclusive with) the KDE one, since a user could reasonably want both, e.g. testing across sessions, or a KDE user who also drives things via a systemd unit elsewhere.
• Didn't enable + start immediately in the installer, only enable: at install time the user's own group membership for the vrgb udev rule hasn't taken effect yet (documented elsewhere in the installer as needing a re-login), so starting it immediately would just fail with a permission error. It activates cleanly from the next login onward instead.

System tested on

• Laptop: ASUS Vivobook S14 (S5406SA)
• HID device: ITE5570:00 0B05:19B6, HID_ID=0018:00000B05:000019B6
• Kernel: Linux 7.2.3-arch1-2 (x86_64, #1 SMP PREEMPT_DYNAMIC)
• Distro: Omarchy (Arch-based), version 4.0.0.r2015.g4930677
• Desktop: Hyprland (Wayland), via Omarchy's systemd --user session management (uwsm) — the exact case Autostart restore only supports KDE (XDG autostart); doesn't work on Hyprland/Sway/etc #9 describes as broken with XDG-autostart-only tooling
• systemd: user session manager (systemctl --user) as shipped with this Omarchy release

Testing performed

• bash -n install.sh / bash -n uninstall.sh — both parse cleanly.
• shellcheck install.sh uninstall.sh — no new warnings introduced. The one pre-existing informational warning (SC2162, read without -r) is on the KDE prompt line I followed the same pattern from, not something introduced by this PR; left as-is for consistency with the surrounding code rather than fixing unrelated code in this PR.
• systemd-analyze verify on systemd/vrgb-restore.service — exits 0, no unit-file errors.
• Functional install/enable check — copied the unit into ~/.config/systemd/user/, ran systemctl daemon-reload + systemctl --user enable, confirmed systemd recognized and could manage the unit (this mirrors exactly what install.sh's new prompt does, run manually to avoid re-running the full interactive/sudo installer against a live system that already had vrgb installed).
• Uninstall path reviewed by inspection (not run destructively against the live install, to avoid tearing down other autostart entries on this machine mid-session): confirmed the added block matches the existing KDE-removal block's structure (existence check, remove, confirm message) and that systemctl --user disable --now ... || true won't abort the script under set -e if the unit was never enabled.

Not tested: the actual "survives a real reboot and restores state" end-to-end path for this specific unit, since my daily-use autostart on this machine is currently handled by a separate --now-enabled unit for continuous color cycling (see #8) rather than a one-shot restore. The unit itself is the same pattern already proven to work for that other, more demanding use case (a long-running Restart=always service using the identical graphical-session.target hook), so I'm confident in the mechanism, but wanted to flag exactly what was and wasn't exercised.