feat(autostart): add LaunchDaemon support for headless macOS servers

[resker]

Closes #4983

Summary

Adds limactl autostart enable --condition=boot to register a Lima instance
as a system-level LaunchDaemon. The VM starts at boot without requiring a user
login session, enabling headless macOS server deployments.

Also unifies the existing start-at-login functionality under the new
limactl autostart command and deprecates limactl start-at-login.

Commands

# Start at user login (LaunchAgent on macOS, systemd user service on Linux)
limactl autostart enable k3s

# Start at system boot, before any user login (macOS only, prompts for sudo)
limactl autostart enable --condition=boot k3s

# Remove registration (auto-detects which type is installed)
limactl autostart disable k3s

Design

Privilege model: limactl itself stays non-root (the existing root check
is not bypassed). The --condition=boot path execs sudo internally for
exactly two operations — writing to /Library/LaunchDaemons/ and running
launchctl bootstrap system — and prompts for a password once at install time.

UserName plist key: launchd runs the daemon process as the specified user
(defaulting to $USER), so the Lima instance runs under the correct user's
home directory and config without requiring that user to be logged in.

Runtime: the daemon plist calls limactl start <instance> --foreground,
consistent with the existing LaunchAgent approach. Normal limactl start/stop
continues to work; no privileged runtime operations are needed.

Changes

• pkg/autostart/launchd/io.lima-vm.daemon.INSTANCE.plist — daemon plist template
• pkg/autostart/launchd/launchd.go — GetDaemonPlistPath, DaemonServiceNameFrom, DaemonTemplate
• pkg/autostart/managers.go — extraTemplateVars field on TemplateFileBasedManager
• pkg/autostart/managers_darwin.go — DaemonManager(userName string) constructor
• pkg/autostart/managers_linux.go, managers_others.go — DaemonManager stubs
• cmd/limactl/autostart.go — limactl autostart command group (cross-platform)
• cmd/limactl/autostart_darwin.go — macOS: login → LaunchAgent, boot → LaunchDaemon
• cmd/limactl/autostart_others.go — non-macOS: login only, boot returns unsupported error
• cmd/limactl/start-at-login.go — marked deprecated
• cmd/limactl/main.go — register autostart subcommand
• website/content/en/docs/usage/autostart.md — new documentation subpage

Testing

• Unit tests added for GetDaemonPlistPath, DaemonServiceNameFrom, and daemon plist rendering
• Manually tested on Apple Silicon Mac Mini (macOS 26, arm64) running a k3s instance
• VM started automatically after reboot with the LaunchDaemon installed
• HA (Home Assistant in k3s) confirmed healthy post-reboot

Notes

• --condition=boot is macOS only; other platforms return an unsupported error
• Developed with AI assistance

---

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license and I have signed off all commits per the DCO.

[AkihiroSuda]

@resker May I confirm that your commits were DCO-signed by you human, not by a bot?
Asking because the commits were pushed extremely quickly after my review 🙂

[resker]

@resker May I confirm that your commits were DCO-signed by you human, not by a bot? Asking because the commits were pushed extremely quickly after my review 🙂

@AkihiroSuda - yes, confirmed... I am not now nor have I ever been a bot :-) The turnaround assisted by AI tools (everything reviewed and submitted by me though).

[AkihiroSuda]

@resker May I confirm that your commits were DCO-signed by you human, not by a bot? Asking because the commits were pushed extremely quickly after my review 🙂

@AkihiroSuda - yes, confirmed... I am not now nor have I ever been a bot :-) The turnaround assisted by AI tools (everything reviewed and submitted by me though).

Sorry for doubting you 😅
You are very productive!

[AkihiroSuda]

Thanks, LGTM after squashing commits.

WIll merge after the release of v2.1.2

[AkihiroSuda]

@resker Could you squash the commits?

[resker]

@AkihiroSuda - Squashed ( the lints check seems to be a network error in the link-checker).

Should #5086 and #5088 (follow up refinements to this) be tagged impact/changelog / milestone v2.2.0 as well?