fix(engine): use OpenSSL-backed libssh2 on Windows so SSH remotes work

[alcalaperez]

Problem

On Windows, any SSH remote operation (clone/fetch/pull/push) against a server whose host key is ssh-ed25519 or ECDSA — GitLab instances by default — fails before authentication is even attempted with:

failed to set hostkey preference: The requested method(s) are not currently supported; class=Ssh (23)

Root cause chain:

• libgit2 builds a host-key algorithm preference list from the user's known_hosts entries for the host and hands it to libssh2_session_method_pref().
• On Windows, libssh2-sys compiles libssh2 with the WinCNG crypto backend, which cannot negotiate ssh-ed25519 or ECDSA host keys at all (RSA-SHA2 only since libssh2 1.11.0).
• When the preference list contains only algorithms the backend doesn't support, libssh2 fails the call and libgit2 aborts the session. Known upstream: libgit2#6454, libgit2#6612, and the identical failure in jj-vcs/jj#3322.

In practice: OpenSSH stores the ed25519 key on first connect (its default preference), so a Windows user with a normal known_hosts simply cannot use SSH remotes at all. With an RSA-only entry the error changes to a certificate failure once the server stops offering ssh-rsa.

Fix

Add a Windows-only direct dependency on libssh2-sys with openssl-on-win32 + vendored-openssl. Cargo feature unification applies it to the transitive git2 → libgit2-sys → libssh2-sys chain, so the vendored libssh2 builds against the vendored OpenSSL (which the release pipeline already compiles for libgit2's HTTPS side) instead of WinCNG, and negotiates ed25519 / ECDSA / RSA-SHA2 like the git CLI. macOS/Linux resolution is untouched (Cargo.lock gains exactly one dependency edge).

Trade-offs:

• Local Windows builds now need Perl on PATH (e.g. Strawberry Perl) for the vendored OpenSSL Configure step. Release CI on windows-latest already ships Strawberry Perl. Documented in docs/Development.md.
• Slightly larger Windows binary (static OpenSSL).

Verification

• cargo check and a full debug cargo build pass on Windows 11 / MSVC; the build log confirms the new chain openssl-src → libssh2-sys → git2 → app link with the OpenSSL backend active.
• End-to-end on Windows 11: cloning from a self-hosted GitLab over ssh://git@…:2222/… presenting an ssh-ed25519 host key. Before: the error above. After: clone completes and public-key authentication proceeds normally.

CHANGELOG.md carries the user-facing entry.

[cheat2001]

Thanks, this checks out. I confirmed the WinCNG backend has ed25519 and ECDSA compiled out, so OpenSSL is the right call. One correction to the write up: libgit2-sys only pulls OpenSSL on unix, Windows uses WinHTTP, so this adds an OpenSSL build to the Windows compile rather than reusing one. The Windows CI job went from under 3 minutes to 23 on a cold cache. I'm fine with that. I rebased the branch to move the changelog bullet under the existing Fixed section.

[cheat2001]

Landed on main as b1d0f9b and it ships in 0.15.0. GitHub shows the PR as closed rather than merged because I fast-forwarded main past your commit, but it is your commit, author and all. Thanks.