Feat: decouple execution-mode switching from probing, unify the Run control, and supporting store refactors

[pcolt]

Note: merge first #208 than re-target to main before merging

It closes #204

• Update CHANGELOG

Overview

Lift execution-mode selection out of SettingsModal and into the always-visible top-right overlay, unify the two Run controls into one, and make mode-switching both lightweight (no re-probe) and correct (never runs a stale configuration).

Since #203, the submit primitives take a self-contained config bag, so the active mode no longer needs to be committed through a probe. This PR turns the mode into a pair of overlay selectors — location (local/remote) and mode (coral/executable/pipeline) — and reorganises probe results so each target keeps its own validated payload.

Data model

Each target's payload lives in its natural store keyed per location: registryStore holds a local and a remote coral node registry; parametersStore holds a local and a remote executable parameter tree (now persisted).
Only a small status per backend kind still lives on each target (ExecutionTargetSettings.probes), giving 4 slots total across local/remote × coral/executable.
Live getters resolve against an internal activeLocation set by the switch orchestration, so switching location instantly changes what the palette / editor / submit see with no hydration copy, and per-location edits persist automatically. Execution location/backendKind are moved into their own persisted executionSelection store, decoupled from the { local, remote } runner config in settingsStore (which never reads that selection — every selection-dependent member takes it as an explicit argument).

UX

The overlay hosts the two selectors (replacing the read-only badge and the standalone view toggle); pipeline requires remote (enforced by disabling the invalid option). Switching to a combination that was never validated raises a toast pointing to Settings, and runs are blocked by a pre-submit guard.
SettingsModal's Save & Sync becomes an explicit Validate & Sync for the current mode's paths.
The Run control is unified in the sidebar (single → job config; pipeline → run pipeline), and all the other buttons in the old pipeline toolbar move in sidebar too.

Cleanup riding along

ProbeResult is slimmed to { ok, message, syncedAt } — probe status now lives per target × backend kind (ExecutionTargetSettings.probes), dropping the old flat AppSettings.lastProbe. Manual "Import Nodes" now merges into whichever location is active, rather than clobbering a single shared registry.

resized-pipeline.mp4

Summary

• feat: overlay location/mode dropdowns (ExecutionBadge becomes interactive) replacing the standalone view toggle; the dropdowns write the two leaf stores directly
• feat: execution location/backendKind moved into a dedicated persisted Svelte selection store (executionSelection, key execution_selection), decoupled from the electron-persisted runner config; the app reopens in the last location+mode
• refactor: settingsStore stays a pure config store — selection-dependent members (getParametersFileName, saveParametersFileName, getProbe, recordProbe) take location/backendKind as explicit arguments; it never imports the selection store
• feat: per-location coral registries in registryStore (internal activeLocation, persisted { local, remote }, best-effort migration from the old flat registered_nodes)
• feat: per-location executable parameter trees in parametersStore, now persisted (execution_parameters)
• refactor: slim ProbeResult to { ok, message, syncedAt }; probe status stored per target × backend kind (ExecutionTargetSettings.probes), dropping AppSettings.lastProbe
• refactor: probe IPC takes a focused ProbeRequest { location, backendKind, target } (not the whole ExecutionSettings) and returns { status, metadata }; the renderer routes metadata to the per-location store
• feat: unified sidebar Run for single + pipeline; move the pipeline toolbar (add-stage, import/export) into SidebarButtons; PipelineCanvas becomes a pure canvas
• feat: manual "Import Nodes" merges into the active location's registry (shallow key-merge)
• refactor: SettingsModal's location/backend-kind radios no longer change the active mode (that is now the overlay's job) — they select which combination to configure and Validate & Sync, seeded from the active selection when the accordion opens; Save & Sync → "Validate & Sync" with per-combo probe status
• feat: pre-submit config guard (coral single + pipeline) blocking runs for un-validated combinations; switching to an un-validated combination toasts a hint

Test plan

• npm run check, npm run check:electron, npm test pass (registry/graphParser tests adjusted for per-location load).
• Validate remote/coral + remote/executable in Settings, then switch between them in the overlay: instant, correct registry/params, no re-probe.
• Switch to a never-validated combination → toast prompts Settings; the run is blocked until validated.
• remote/executable ↔ local/executable each load their own params (no mismatch); edits persist per location across switches and restart.
• Import Nodes while in a coral combo → merges into that location's registry; persists across restart; the other location's registry is unaffected.
• Single coral + executable runs submit as before (remote Docker Slurm + local); pipeline runs from the sidebar with correct --dependency; PipelineCanvas has no toolbar.
• pipeline disabled while location is local; local disabled while mode is pipeline.
• Restart in each combination → the correct per-location registry/params load without a forced re-sync; the app reopens in the last selected location+mode.
• coral ↔ executable ↔ pipeline ↔ back remembers the coral/executable choice (backendKind survives a pipeline detour).
• With the overlay on remote/coral, use the Settings radios to configure & Validate a different combination (e.g. local/executable) → its status turns valid without changing the canvas/overlay (no palette flip); switching the overlay to it later shows no "not validated" toast.