#510 copy method reports success when scp exits non-zero (e.g. 255)

Description

The @swamp/ssh copy method returns method status succeeded even when the underlying scp exits non-zero (e.g. 255, "Connection closed"). The failure IS recorded in the per-host runResult (exitCode: 255, stderr), but it is not propagated as a method/step failure — so workflows with dependsOn: { condition: succeeded } continue as if the file copied when it did not.

Steps to reproduce

1. Define an ssh-transport host whose connection will fail (e.g. a proxyCommand pinning a stale IdentityAgent socket).
2. Run copy (direction to) of a local file to that host.
3. scp exits 255 with stderr like Connection closed by UNKNOWN port 65535 / scp: Connection closed.

Observed: the saved runResult shows exitCode: 255 and the stderr, but the method-summary reports copy … succeeded, producing 1 resource (runResult), and a dependent workflow step (gated on succeeded) proceeds — operating on a file that was never copied.

Expected

copy (and by symmetry exec/script, if they don't already) should mark the method failed when the transferred process exits non-zero, so succeeded/completed dependency conditions gate correctly.

Impact

Silent "data not copied" — downstream steps act on missing files. This masked a real failure in a build pipeline: a staged cloud-init snippet wasn't copied, yet the workflow proceeded to clone/configure the VM.

Environment

@swamp/ssh 2026.05.29.2, swamp 20260530.005533.0. The 255 here was a stale IdentityAgent; the bug is the success-on-nonzero-exit masking, independent of the cause.

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

Environment

• Extension: @swamp/ssh@2026.05.29.2
• swamp: 20260530.005533.0-sha.1c117111
• OS: linux (aarch64)
• Deno: 2.7.14+19bd3d8
• Shell: /bin/bash