Driver capability registry: declare richer execution capabilities at driver design time

Context

Follow-up to swamp-club #83 ("Workflow-level workspace for docker driver"), which landed the first driver capability: `sessionSupport: boolean`, declared statically on every `ExecutionDriver` and read at driver-registration time. That issue deliberately shipped one capability to avoid over-engineering, but during the design we identified a broader family of execution-time properties that driver authors should be able to advertise statically. This issue captures that design space so the follow-up work has a permanent home.

Problem

Today, the `ExecutionDriver` interface (`src/domain/drivers/execution_driver.ts`) describes what a driver does (execute, initialize, shutdown) but not what it is capable of. That means:

• swamp cannot validate at plan time whether a workflow's requirements are compatible with the resolved driver — failures surface at runtime after partial execution.
• `swamp driver list` and similar introspection commands cannot surface meaningful capability information to users choosing between drivers.
• Extension driver authors writing drivers for environments with hard constraints (Lambda 15-minute cap, single-threaded runtimes, no streaming stdout, etc.) have nowhere to express those constraints; swamp treats every driver as if it had the same capabilities as the built-in docker driver.
• Future workflow features that depend on driver capabilities (e.g. concurrent step execution inside a session, streaming log forwarding, in-session file transfer, long-running sessions) have no place to check whether the driver supports them.

Proposal

Grow the `ExecutionDriverCapabilities` type introduced in #83 into a richer (still conservative) registry. Candidate fields, in rough priority order:

`supportsConcurrentSteps: boolean`

Can the driver execute multiple steps in parallel within a single session? Useful for `forEach` fan-out against a session-capable driver. Docker exec is concurrent-safe; a single-threaded virtio-serial QEMU console is not.

`maxSessionLifetimeSeconds: number | undefined`

Hard cap on how long a session can live. Undefined means unbounded (docker, raw, qemu). A hypothetical Lambda-with-session driver would declare 900. swamp validates at plan time that the workflow's estimated or configured runtime does not exceed the cap; users get an actionable error rather than a mid-run termination.

`supportsStreamingOutput: boolean`

Does the driver emit logs in real time via `onLog` callbacks, or only batch at step end? Affects TUI and interactive log rendering decisions.

`supportsFileTransfer: boolean`

Can the driver push/pull files between swamp's host and the execution environment? Docker: yes (`docker cp`). SSH: yes (`scp`/`sftp`). Lambda: via request/response payload only. This is distinct from session filesystem sharing — it's about moving bytes in and out of the environment regardless of session support.

`supportsInteractiveInput: boolean`

Can the driver forward stdin from the user to a running step? Matters for debugging flows, interactive tools, pagers.

`persistsBetweenRuns: boolean`

Can a session (or some artifact of a session) survive a swamp process restart? Docker containers can (they keep running after swamp exits). A local raw temp dir cannot (it is tied to swamp's process). Relevant for robustness to swamp restarts mid-workflow.

`requiresNetworkAccess: boolean`

Does the driver need to reach out to a control plane / image registry / cloud API to function? Affects offline-mode UX and error messages when a user is on a plane and their driver quietly fails.

Non-goals for this issue

• Do not ship all of these in one go. Each capability should be justified by a concrete workflow feature or user pain point before it lands.
• Do not try to compress these into a single capability taxonomy or hierarchy. They are independent flags; keep them independent.
• Do not retroactively change driver-registration ergonomics for built-in drivers. Every new capability should default to a value that preserves today's behavior for existing drivers that do not opt in.

Implementation pattern

Each capability follows the same pattern established in #83:

1. Add the field to `ExecutionDriverCapabilities` with a default that preserves existing behavior.
2. Update `driver_type_registry.ts` to read and expose the capability.
3. Add validation in `WorkflowExecutionService` (or wherever the capability is load-bearing) that errors at plan time with actionable remediation.
4. Update `swamp driver list` / `swamp driver show` to surface the capability.
5. Document the capability in the `swamp-extension-driver` skill so extension authors know to set it.
6. Add capability-aware tests.

References

• swamp-club #83 — workflow-scoped driver execution (this issue's parent)
• `src/domain/drivers/execution_driver.ts` — where capabilities will live
• `src/domain/drivers/driver_type_registry.ts` — registration surface
• `.claude/skills/swamp-extension-driver/` — author documentation