Feat: legible working directory naming; group stage jobs in the job table; pipeline import/export

[pcolt]

Part of #202.

Overview

Directory names are currently pure timestamps: pipelines have used pipeline-<ts> since the original pipeline MVP (PR #205), and single runs gained their own isolated run-<ts> subdirectory in PR #206. This is neither meaningful to a user (or coral-visualizer, which lists/groups files by folder name under shared-data) trying to find/inspect a specific run's output, and the job table has no way to show which rows belong together.

This issue is split into independent phases, each landing as its own reviewable slice; a deeper plan file exists per phase under this folder (plan-phase1.md, etc.), written just before that phase starts — not all up front:

• Phase 1 — legible naming + visual identification, no new persistence. (PR Feat: legible run/pipeline naming + Working Directory job-table column + Pipeline import/export #208) Optional custom name at submit time (single run and pipeline), slugified into the folder name with collision-safe auto-suffixing; JobsTable.svelte gains a "Working Directory" column showing the raw, already-tracked jobIdMap path verbatim (no parsing, so the table stays decoupled from the naming convention). No new store, no run-record type, no clustering/group-header UI — just a display column a user can scan.
• Phase 2 — pipeline import/export. (PR Feat: legible run/pipeline naming + Working Directory job-table column + Pipeline import/export #208) Download the current pipeline (nodes/edges) as a JSON file and re-import it, mirroring the existing "Coral graph from file" pattern. No persistence backend, no naming/identity decisions — just a portable file.
  Along the way, the pipeline data model is reshaped to mirror the CORAL graph export: nodes are keyed by type ('coralStage'/'executableStage') instead of a separate kind field, and the download/import file wraps { nodes, edges } under a pipeline key plus a version/author/date_time_utc envelope.

Persisting pipeline definitions for later reload (as opposed to one-off file export/import) was originally scoped here as a "Phase 2" built on local Electron store, but that assumed a persistence mechanism without checking whether it made sense next to the app's existing coral-remote-server-backed Projects system (which already saves/shares/lists CORAL graphs and stores an untyped graph JSON payload — a Pipeline could reuse it with no big backend changes or create a new table). That decision is deferred and now tracked as its own item in issue202-body.md's "What's still open" list, not here — this issue no longer covers it. Persisting to coral-remote-server for shared/multi-user run history remains a separate, also out-of-scope concern (see issue202-body.md).

Naming (Phase 1's core design)

Today directory names are purely mechanical — meaningful only as "made at this time," not to a user trying to find a specific run again. Recommendation: keep directory names legible on disk, with an opt-in custom name, and surface that name in the job table directly from existing data.

• Default stays as today: run-<timestamp> / pipeline-<timestamp> when the user submits without naming anything — zero friction, unique by construction.
• Optional custom name at submit time: a confirmation modal (single job and pipeline) lets the user type an optional name before submitting. If given, it's slugified into the folder name (run-<slug> / pipeline-<slug>) instead of the timestamp. If a slug collides with an existing directory, append a short disambiguator (timestamp) automatically rather than blocking submission.
• Job table shows the raw working directory, not a parsed name: jobIdMap already records each job's workingDirectory. Displaying it verbatim as a new column needs zero parsing logic and keeps JobsTable.svelte fully decoupled from the run-*/pipeline-* naming convention — if that convention ever changes, the table doesn't need updating. A user can visually spot which rows share a pipeline run by matching the (now legible) path, and the same raw value is available for filtering later, without a dedicated run-record store.

Critical files

Phase 1 only:

• src/lib/utils/slugify.ts — slugify(), buildDirName().
• src/lib/utils/sshMessages.ts — new ensureUniqueRemoteDir(), optional runName param on the four exportAndEval* entry points.
• src/lib/orchestration/pipelineOrchestrator.ts — optional runName param on runPipelineRemote.
• A new confirmation modal for entering an optional pipeline run name before submit; JobConfigModal.svelte gains the same optional field for single runs.
• src/lib/components/layout/JobsTable.svelte — new "Working Directory" column showing jobIdMapState.getJobWorkingDirectory(...) verbatim.

Out of scope

• Persisting pipeline definitions for later reload (as opposed to one-off file export/import); tracked as its own item in issue202-body.md, not here.
• coral-remote-server-backed persistence (shared/multi-user run history, cross-machine access) — deliberately deferred, see issue202-body.md.
• Artifact/file passing between stages — unrelated, tracked separately in the issue202-body.md design doc.
• Local pipeline execution — unrelated to this issue.
• Clustered/grouped rendering (header row + nested stage rows) in the job table — descoped in favor of the simpler "Working Directory" column for now; revisit only if the column proves insufficient in practice.