#522 Support vault-resolved private key content in transport auth (not just file paths)

Problem

@swamp/ssh's transport auth currently requires identityFile — a path to a private key file on disk. When using vault.get() expressions (e.g. via @swamp/1password), the resolved value is the PEM key body itself, not a file path. There is no way to use a vault-stored private key with @swamp/ssh without either:

1. Relying on ssh-agent being pre-loaded (fragile in CI, not self-contained)
2. Writing the key to disk externally before invoking the model (violates the principle that swamp models should be self-contained)

Proposed solution

Add support for inline key content in the transport auth configuration, e.g.:

transport:
  auth:
    kind: key
    identityContent: ${{ vault.get(my-vault, SSH_PRIVATE_KEY) }}

When identityContent is set, @swamp/ssh would internally write the PEM body to a temp file (mode 0600), use it for the SSH session, and clean up in a finally block — the same withTempKey pattern already used by custom models that work around this limitation.

Alternatives considered

• ssh-agent: Works but requires the agent to be pre-loaded before the swamp workflow runs. Not self-contained, breaks in fresh CI environments.
• Custom extension model: This is what we built — we reimplement SSH execution with withTempKey to work around this gap. Duplicates core SSH functionality that @swamp/ssh already provides.
• identityFile accepting a vault expression: Doesn't work because the expression resolves to key content, not a path.

Impact

Any user who stores SSH private keys in a vault (1Password, HashiCorp Vault, etc.) and wants to use @swamp/ssh hits this gap. The workaround is writing a custom model that duplicates SSH execution logic, which defeats the purpose of having a shared SSH extension.

Upstream repository: https://github.com/systeminit/swamp-extensions

Environment

• Extension: @swamp/ssh@2026.06.01.1
• swamp: 20260527.235818.0-sha.ed572875
• OS: darwin (aarch64)
• Deno: 2.7.14+19bd3d8
• Shell: /bin/zsh