fix(ssh): preserve argv boundaries for multi-arg remote commands

[paulocsanz]

railway ssh svc sh -c 'redis-cli -a "$PW" PING && echo ok' never worked: ssh(1) concatenates every remote-command word with single spaces into one string for the remote login shell, so argv boundaries don't survive — sh -c received only redis-cli as its script, the quoted string leaked into $0/$1, and && echo ok ran as a second command.

What

Shell-quote each remote-command word (shlex::try_quote) when the caller passed more than one, so the remote shell's re-split reproduces the caller's argv exactly — docker exec/kubectl exec semantics. A single word keeps passing through raw: it IS the remote shell line (today's documented usage, e.g. railway ssh 'complex | pipeline'), and quoting it would collapse the whole line into one command word.

Applied at run_native_ssh_with_opts, the choke point — railway ssh and railway sandbox both get it; railway code passes a single prebuilt word and is unaffected (all callers audited).

Verification

• Unit tests on the new helper, including the round-trip invariant: join-with-spaces + shlex::split must reproduce the original argv (quotes, spaces, $, ;|, empty words).
• cargo test: 932 passed.
• Live e2e against a Railway service:

  cargo run -- ssh -s Redis-1 sh -c 'redis-cli -a "$REDIS_PASSWORD" --no-auth-warning PING && echo chained-ok'
  → PONG
  → chained-ok
  

  (released CLI mangles this into sh -c redis-cli ...).

Same-class issue left out of scope: run_tmux_session interpolates the session name unquoted into tmux new-session -A -s {}.