Frontend intent single-owner for per-peer commands

[JohnSL]

Summary

After the peer-session-actor refactor (spec 019) lands, add a frontend intent layer that owns "one operation in flight per peer" for user-facing operations (download CDI, read config, write config, query SNIP). This provides:

• A single "operation in progress" indicator per peer in the UI.
• A cancel-then-restart primitive for user-initiated re-issue.
• Coalescing of redundant user commands before they hit Tauri (e.g. clicking "Download CDI" twice while one is in flight).

Areas

area/frontend, area/orchestration

Origin

Spec 019-peer-session-refactor — Clarification 5 (2026-07-05).

Deferred from that spec's original Slice 7 because backend serialization (per-peer PeerSession) already closes the correctness gap; the frontend layer is UX polish, not a correctness requirement.

Prior Work

• specs/019-peer-session-refactor/spec.md — Clarification 5 and Target Architecture / Frontend layer sections.
• Backend PeerSession per-peer command serialization (spec 019 Slices 1–6).
• Existing frontend surfaces that would benefit: discovery modal, CDI download progress, config-editor save flow, SNIP/PIP refresh triggers.

Open Questions

• Placement: Where does the intent owner live — a new orchestrator in app/src/lib/orchestration/, or an extension of the existing discoveryOrchestrator?
• Coalescing key: Does the intent owner coalesce by NodeID alone, or by (NodeID, operation)? Different operations against the same peer could be queued rather than coalesced.
• Cancel semantics: Is a user-initiated re-issue a hard-cancel (send PeerCommand::Cancel and wait) or a drain-then-cancel (wait for current op to finish, then issue new one)?
• UI surface: Where does the "operation in progress" indicator live — per-node in the discovery panel, in a global status bar, or both?