feat(daemon): add optional managed startup and crash recovery

[coygeek]

Summary

Provide an optional, user-facing way to keep the Loopany daemon running across login, reboot, and unexpected process exit without requiring users to author operating-system service files themselves.

Problem to solve

loopany up starts a detached process that survives the invoking shell, but Loopany does not provide a supported login/startup service or crash supervisor. After a reboot or unexpected daemon exit, recurring work remains pending until the user notices and manually runs loopany up again.

A durable macOS installation required an external LaunchAgent running loopany up --foreground. That restores reliability, but the service is invisible to Loopany's setup, status, stop, and update workflows.

Proposed behavior

Add an optional CLI-managed startup mode on supported host platforms. Once enabled, it starts the foreground daemon when the user logs in or the machine boots, restarts unexpected exits, reuses the stored server URL and device identity, and can be inspected or disabled through Loopany.

The first release may support one platform. The product contract is the lifecycle behavior, not a requirement to ship every service manager at once.

Acceptance criteria

• A user can enable and disable managed startup from the Loopany CLI without editing a plist, systemd unit, shell profile, or project folder.
• After login or reboot, the daemon reconnects using its stored identity without a terminal command.
• An unexpected daemon exit is restarted with bounded behavior and diagnosable logs.
• An intentional stop or uninstall is respected and does not immediately trigger an unwanted restart.
• Repeated enable operations are idempotent and preserve the one-daemon-per-machine invariant.
• loopany status distinguishes local daemon state, server connection state, and managed-startup state.
• The update workflow preserves or safely restarts the managed service without leaving two daemon versions polling concurrently.
• Device credentials remain in protected local storage and are not written to process arguments or world-readable service definitions.

Affected area

• packages/daemon setup, status, stop, and update lifecycle
• User-level setup documentation
• Platform lifecycle tests through injected service-manager seams

Non-goals

• Running the machine-side coding-agent daemon inside the server container.
• Managing the Loopany web server or database.
• Requiring a privileged system-wide service when a per-user service is sufficient.
• Supporting every operating system in the first implementation.

Alternatives considered

• Keep detached startup only: simplest, but reboot and crash recovery remain manual and invisible to status.
• Publish service-file examples only: reduces implementation work, but leaves lifecycle, updates, logs, and single-daemon fencing outside the CLI.

Supporting context

• Loopany describes itself as infrastructure for recurring work and documents one daemon per machine.
• packages/daemon/src/daemon.ts already exposes loopany up --foreground, which provides a supervision-friendly process lifecycle.
• packages/daemon/src/pidfile.ts and packages/daemon/src/control.ts already provide process identity and local status primitives.
• No supported managed-startup workflow currently exists in the repository.

Blocked by

None — can start immediately.