[FEATURE] SSH connections: support OpenSSH certificate authentication (CertificateFile) or delegate to system ssh

Problem

The desktop app's "Add SSH connection" feature cannot connect to hosts that require OpenSSH user certificate authentication. The embedded SSH library (ssh2) does not implement the OpenSSH certificate extension and ignores the CertificateFile directive in ~/.ssh/config.

This makes the feature unusable with Azure AD SSH login (aadsshlogin, Microsoft's standard for Entra-joined Linux VMs), where sshd only accepts a private key when a short-lived AAD-signed certificate is presented alongside it. It equally affects any org using an SSH CA (HashiCorp Vault SSH, Smallstep, Netflix BLESS, etc.).

Reproduction / evidence

Azure VM with AAD login enabled; az ssh config generates a key plus certificate under ~/.ssh/az_ssh_config/<ip>/:

• Terminal: ssh <host> (OpenSSH, honors CertificateFile) -> connects.
• Terminal: ssh -i id_rsa <host> with cert omitted -> Permission denied (publickey) -- confirming the cert is the deciding factor.
• Desktop "Add SSH connection" with the same host/key -> key rejected, falls back to a password prompt the server won't accept. No combination of Name / Host / Port / Identity File works.

Why it matters

Certificate-based SSH is the security-conscious enterprise default (short-lived creds, conditional access, no standing keys). The current workaround -- adding a long-lived plain key to authorized_keys -- is exactly what these orgs prohibit.

OpenAI's Codex app already enables this exact workflow. Its SSH remote-connections feature discovers hosts from ~/.ssh/config and delegates the connection to the system OpenSSH client, so certificate auth works transparently -- the same AAD-protected VM that Claude Code's dialog cannot reach works out of the box as a Codex remote project. For teams on cert-based infrastructure, this single gap is the deciding factor that moves remote-VM agent workflows from Claude Code to Codex, despite Claude Code otherwise being the preferred tool.

Related: #48116 reported the host-certificate side of the same gap (Teleport proxy, *-cert-v01@openssh.com host keys) and was auto-closed as stale. Both stem from the embedded library lacking OpenSSH certificate support.

Suggested fix (either resolves it)

1. Support OpenSSH certificates in the embedded client: honor CertificateFile and offer <algo>-cert-v01@openssh.com auth, plus certificate host-key formats.
2. Or add an option to delegate the transport to the system ssh binary. Since the config already lives in ~/.ssh/config, this inherits certs, ProxyJump, agent, etc. for free. This is the approach Codex takes, and it inherits the user's full OpenSSH capability set with no per-feature work.

Alternatives / workarounds

• Current workaround: skip the desktop connector entirely -- open a terminal ssh session, where real OpenSSH presents the cert, and run claude on the remote host. Works, but loses the desktop app's remote-project integration.
• Rejected workaround: append a plain long-lived key to authorized_keys and point the dialog at it. This is exactly the standing credential outside conditional access / cert rotation that cert-based orgs prohibit.
• Other tools: OpenAI Codex delegates to system OpenSSH and handles this setup out of the box.

Use case

1. Org runs its dev/pipeline VM as an Entra-joined Azure Linux VM with AAD SSH login; a scheduled task re-mints the short-lived AAD cert via az ssh config every 15 minutes.
2. Terminal ssh <alias> works with zero manual steps; every OpenSSH-based tool, including Codex remote projects, connects fine.
3. Claude Code desktop's "Add SSH connection" is the one tool in the stack that cannot connect, so project-based remote work happens in other tools.