#343 Official @swamp/ssh extension supporting multiple SSH transport styles

Problem statement

Some swamp users currently rely on the community @keeb/ssh extension for programmatic SSH from models and workflows. It supports traditional key-based auth with vault-stored keys, which covers the most common case but leaves several modern SSH topologies unaddressed:

• Tailscale SSH — tailscale ssh user@host uses tailnet identity (Tailscale ACL + IdP) instead of a static SSH key. This is increasingly common in production environments that have adopted Zero Trust networking. There is no clean way to express "SSH to this host via Tailscale" through @keeb/ssh today.
• Bastion / jump-host topologies — ssh -J <bastion> <target> is the standard way to reach hosts that aren't directly routable. @keeb/ssh doesn't expose ProxyJump configuration.
• Custom ProxyCommand — e.g., AWS SSM Session Manager (ssh -o ProxyCommand="aws ssm start-session ...") lets you SSH to EC2 instances with no inbound SSH port open. No first-class support today.

Because there is no official extension, each team that needs one of these styles either forks @keeb/ssh, writes their own bespoke model that shells out to ssh, or works around it with command/shell. This fragments the ecosystem and produces inconsistent vault handling, error reporting, and audit semantics.

Proposed solution

Provide an official @swamp/ssh extension that exposes a uniform model interface to multiple SSH transport styles. Callers specify the target host and a via (transport) selector; the model handles the underlying invocation.

Sketch of the interface:

// Traditional SSH (parity with @keeb/ssh)
{ via: "key", host: "...", user: "...", vaultKey: "..." }

// Tailscale SSH
{ via: "tailscale", host: "...", user: "..." }

// Bastion / jump host
{ via: "bastion", host: "...", user: "...", bastion: "user@bastion-host", vaultKey: "..." }

// ProxyCommand (e.g. AWS SSM)
{ via: "proxy-command", host: "...", user: "...", proxyCommand: "aws ssm start-session --target i-..." }

Methods at minimum:

• run — run a single command, capture stdout/stderr/exit
• script — upload and execute a script
• copy — scp/rsync-style file transfer

Vault handling should match the existing swamp convention (read-secret, never write to disk; pipe into ssh-agent or use file-descriptor substitution where the underlying tool requires a path).

Alternatives considered

• Continue with @keeb/ssh — community-maintained, no Tailscale or bastion support, no roadmap commitment.
• Each consumer wires their own SSH model — duplicated logic, inconsistent vault handling, harder to audit fleet-wide.
• Use command/shell everywhere — explicitly discouraged by swamp guidance ("command/shell is for ad-hoc one-off shell commands, NEVER for wrapping CLI tools or building integrations").

Context

Filed in the context of a project that needs a swamp posture model that audits our fleet's SSH configuration; today we'd reach for @keeb/ssh, but it can't carry a Tailscale-SSH connection — so we're either forking it or shelling out, neither of which is a good long-term answer.