#519 Persistent, queryable workflow runs (status / cancel from any shell)

Why this matters

swamp workflow run is currently shell-attached: the CLI process owns the run, and the run only exists for as long as that terminal stays alive. That becomes a real ergonomic problem the longer a workflow takes:

• Terminal death loses your view, not your work. A laptop sleep, an SSH drop, or an accidental Ctrl-C kills the CLI process — but the docker containers it kicked off keep running, lockfiles stay held, and there's no supported way back in to either watch them finish or kill them cleanly.
• No second-pane visibility. Long parallel workflows (e.g. fan-out reviewer or evaluator jobs) leave you sitting on one terminal for many minutes, unable to check progress from anywhere else. If you started the run on a remote machine, peeking from a laptop means another ssh and tail -f against a log pipe you happened to capture.
• No clean cancel. If a workflow misfires, the only abort path is docker kill on the running step's container — which leaves swamp's lockfile and any partial datastore writes in an inconsistent state. There is no swamp workflow cancel that knows how to tear down cooperatively and release the lock.
• Multi-user setups are blind to each other. On a shared swamp repo (a team's monorepo, a CI worker), collaborators can't see what runs are in flight, who started them, or what they're waiting on.
• Failed runs leave orphaned state. When something crashes mid-run, there's no canonical record of "this run existed, here's its DAG position when it died" — reconstruction relies on whatever local log pipe got captured.

The friction compounds for any workflow that takes more than a couple of minutes. Workflows with parallel jobs (reviewers, evaluators, batch processors) sit in that window almost by definition.

Proposed shape

A small surface of commands that operate against runs as named, addressable objects:

Command	Purpose
swamp workflow status <run-id>	Show DAG state, current step, started/finished timestamps
swamp workflow logs <run-id>	Tail the run log (streaming or one-shot)
swamp workflow cancel <run-id>	Cooperatively cancel the run; release locks; mark cancelled
swamp workflow list	Recent runs across all workflows in this swamp repo

swamp workflow run would need to emit a run id on submit so it's addressable from then on (or accept --detach to fire-and-forget).

The architecture — where run state is persisted, how step processes are parented, how cancellation is signalled into docker steps, how stale-lock reaping works — is for swamp to decide. These are sketched commands, not an implementation proposal.

Affected components

• swamp workflow run (run id emission, detach flag)
• Workflow execution service (per-run state persistence, cancellation signal propagation)
• Lockfile / datastore lifecycle (stale-run reaping, cooperative release)
• CLI (new status, logs, cancel, list subcommands)