Multi-host daemon architecture: tracking epic

[BunsDev]

Summary

Tracking epic for the four-device multi-host daemon architecture across Coven runtime and Cave GUI.

Architecture Scope

• Linux Server: Daemon 1 hub and single authority for familiar memory, loop state, node registry, and global/per-spoke job queues.
• Mac mini: Daemon 2 stateless stationary executor, polled and dispatched by hub over SSH/Tailscale.
• Dev Workhorse: Daemon 3 stateless compute executor, polled and dispatched by hub over SSH/Tailscale.
• MacBook Air: Cave GUI plus local-only traveling sub-daemon for offline fallback, read-only travel profile cache, local lightweight agents, offline queue, and reconnect delta.

Key Decisions

• Coven runtime remains the authority boundary.
• Cave becomes a hub/sub-daemon client surface.
• Spokes do not initiate contact with the hub; hub polls and dispatches over SSH.
• Daemon 1 wins familiar-memory conflicts; offline results append rather than overwrite.

Child Work

This epic is intentionally split across phase issues for safe implementation.

[BunsDev]

Issue map

• Phase 0 spec: Phase 0: write multi-host daemon architecture spec and repo boundary contract #265
• Phase 1A hub control plane: Phase 1A: build hub node registry, routing table, and persistent job queues #266
• Phase 1B spoke SSH protocol: Phase 1B: add stateless spoke protocol and SSH dispatcher #267
• Phase 1C Cave hub client: Phase 1C: add hub connection config, status, and GUI routing coven-cave#2052
• Phase 2A travel profile/reconcile APIs: Phase 2A: add travel profile and reconcile APIs #268
• Phase 2B Cave traveling sub-daemon: Phase 2B: add traveling sub-daemon, cache, offline queue, and switchover coven-cave#2053
• Phase 3 scheduler intelligence: Phase 3: add multi-host scheduler intelligence and loop redispatch #269
• Failure simulations/release gates: Multi-host failure simulations and release gates #270