feat(hex-ssh): Optional native OpenSSH/scp backend mode

[levnikolaevich]

Context

The current ssh2-based implementation gives us strong control and good safety defaults, but native OpenSSH tooling still has compatibility advantages for enterprise SSH setups.

A separate optional backend mode could improve parity for:

• ProxyJump
• agent forwarding / existing SSH agent behavior
• real-world SSH config compatibility
• transport behavior users already trust from ssh / scp

This is a compatibility track, not a replacement for the current default backend.

Why later than #38 and breadth work

• current single-file correctness and interop confidence matter more than transport substitution
• native backend introduces a different security and UX profile
• this should not regress the stronger fail-closed posture of the current default path

What to do

• Investigate and prototype an optional native OpenSSH/scp backend mode
• Keep it separate from the current ssh2 default path
• Compare behavior and tradeoffs for:
  • host verification
  • timeouts
  • error mapping
  • Windows behavior
  • SSH config compatibility
  • ProxyJump / jump host flows
• Define when native backend should be selected and how it is exposed to users
• Explicitly avoid a weaker default trust model such as StrictHostKeyChecking=accept-new

Schema/API changes

• Likely add backend selection via config/env first
• Do not replace the current default backend in the first pass

Definition of Done

• Backend design is documented
• Capability and risk comparison versus ssh2 exists
• Prototype path is validated on supported platforms
• Host verification and timeout semantics remain explicit
• User-facing selection model is documented

Related issues

• Should follow evidence from: #38
• May benefit from audit shape from: #37
• Independent of recursive transfer breadth in #39

Priority

Medium. This is a compatibility and product-positioning issue, not a blocker for current file transfer correctness.