[Bug]: Desktop app silently takes over the device's existing runtimes under a new profile, breaking session restore for all pre-existing chats/tasks

Deployment type

self-host

Area

Desktop app

What happened?

Title: Desktop app silently takes over the device's existing runtimes under a new profile, breaking session restore for all pre-existing chats/tasks

Environment

• Multica Desktop v0.4.42 (Linux), signed in to a self-hosted server
• Same machine already ran a standalone daemon with the default CLI profile (workspaces root ~/multica_workspaces/) for weeks, plus a second named-profile daemon (unaffected)

What happened

On first sign-in, Desktop created its dedicated profile (~/.multica/profiles/desktop-<host>/) and started its own daemon — as documented. But instead of registering as a separate device/runtime set, it re-registered under the same device name and adopted the existing runtime records (same runtime IDs, now launched_by: desktop), while serving them from a fresh workspaces root (~/multica_workspaces_desktop-<server>/).

Result: every chat/task created before the switch is still bound to those runtime IDs, but its workdir and provider session live under the old profile's root, which the new daemon can't see. Every continuation fails with "session could not be restored" and the agent restarts with no working memory. From the user's point of view, everything silently broke at once, with no error attributable to Desktop.

Expected

Any of these would be fine:

• Let Desktop attach to an already-running daemon on the machine instead of always spawning its own (an opt-in setting would be enough), or
• Have Desktop's daemon register as a distinct device/runtimes so it never adopts runtimes whose state lives in another profile, or
• At minimum, detect the takeover and warn/migrate: "this device already has N runtimes with existing sessions under profile X — adopt (sessions will not restore) / migrate / cancel".

Impact

Silent, wholesale loss of session continuity for every pre-existing chat and task on the device, with no indication that installing Desktop was the cause. Recovery requires manually stopping Desktop, restarting the old-profile daemon, and never opening Desktop again on that machine.

Steps to reproduce

1. Run a default-profile daemon on a machine for a while; create chats/issue tasks.
2. Install Multica Desktop on the same machine and sign in to the same server.
3. Desktop spawns its own profile daemon, which takes over the device's runtime registrations with a new workspaces root.
4. Continue any pre-existing chat → provider session restore fails; agent has amnesia. All pre-existing tasks are affected.

Screenshots (optional)

No response

Additional context (optional)