multica_agent_host: daemon lifecycle via systemd; fix login guard (WDWL-22)

Found provisioning spaceship-earth:

- Login was not idempotent: `multica auth status` prints to stderr (0.6.5),
  and the guard read stdout only, so every run re-logged in and restarted
  the daemon. The guard now reads both streams; the status read is no_log
  because it echoes a token prefix.
- `multica daemon start` / `daemon restart` fork the daemon inside the
  caller's session (Ansible's SSH session scope), outside the systemd user
  unit, which stays inactive: the same orphan seen on haunted-mansion on
  2026-10-21. Start/restart now go through `systemctl --user`, after a
  daemon-reload when autostart was (re)registered. A daemon found running
  outside its unit is stopped first. The unit name is read from
  `autostart status`, so --profile hosts resolve their own unit.

spaceship-earth: second run changed=0, daemon in multica-daemon.service.
Not yet run against haunted-mansion.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

ansible/roles/multica_agent_host/README.md

@@ -307,13 +307,19 @@ Every step reads before it writes:
 | CLI install | `multica --version` equals the pin |
 | Agent CLI install | `command -v <binary>` and its version command |
 | Config | `multica config show` parsed and compared key by key |
-| Login | `multica auth status` already names `multica_server_url` |
+| Login | `multica auth status` already names `multica_server_url` (it prints to **stderr**; the guard reads both streams) |
 | Autostart | `multica daemon autostart status` |
-| Daemon start | `multica daemon status --output json` reports `running` |
+| Daemon start | `systemctl --user is-active <unit>`; a daemon running *outside* the unit is stopped first, then the unit is started |
 
-A binary, config or credential change notifies a `multica daemon restart`
+A binary, config or credential change notifies a `systemctl --user restart`
 handler, which is flushed *before* verification reads the daemon's state back.
 
+The role never calls `multica daemon start` or `multica daemon restart`. Both
+fork the daemon inside the caller's session (Ansible's SSH session scope),
+outside the unit's cgroup. The unit then shows `inactive`, nothing supervises
+the process, and a later `systemctl --user start` collides with it on
+`daemon.lock`.
+
 A converged host reports zero changed tasks.
 
 ## Verification