[idea] Saved machines: adopt a remote server that a service manager (launchd/systemd) runs

[masterfasa]

On macOS, agents in Herdr panes need the logged-in GUI session (Aqua) to read the login Keychain — that's how Claude Code and other CLIs find their credentials. So we run each remote host's herdr server from a per-user LaunchAgent in gui/<uid>.

herdr machine add <host> asks to restart that server, and the restart can't succeed ("server did not stop within 15000ms") because launchd keeps it alive. If we remove the LaunchAgent, Herdr starts its own server over SSH, and panes there lose Keychain access: claude auth status reports loggedIn: false (vs true under the LaunchAgent). Herdr 0.9.5 on both ends, macOS on Apple silicon.

So today, saved machines and Keychain-authenticated agents are mutually exclusive on macOS hosts. Being able to save a machine whose server is run by a service manager (launchd/systemd) — e.g. by adopting it, or restarting it through the service manager — would fix it. Related: #1137.

[Very-Random-Walk]

Same need here with the desktop app's herdr-core (app 0.1.12; core 0.1.17 on the client Mac, 0.1.16 on the remote Macs; macOS 27 on Apple silicon).

We run herdr-core serve on each remote Mac as a LaunchAgent in gui/<uid>, for the same Keychain reason. Those Macs answer SSH before anyone logs in, because Tailscale runs there as a system daemon. After a remote Mac restarts, the app reconnects at the login window: herdr-core connect finds no core and starts its own under SSH. Once someone logs in, the LaunchAgent exits at every respawn because a core is already listening (launchctl print shows spawn scheduled, last exit code 0). Claude Code in that machine's panes then reports Not logged in. Stopping the SSH-started core is not enough: the app reconnects within about a second and starts another one before launchd restarts its own.

So for herdr-core too, it would help to mark a saved machine's core as run by a service manager. connect would then start or wait for that service, showing that the machine is waiting for login, instead of starting its own core. For now we run a small LaunchAgent that swaps the cores after login.