TortoiseGit SSH client change: moving from TortoiseGitPlink to OpenSSH breaks production authentication

A Windows workstation authenticates to a Git remote over SSH without issues when using TortoiseGit, but the same repository and credentials fail on a production or CI machine. The suspected boundary is the SSH client configured under TortoiseGit Settings > Network > SSH client.

By default TortoiseGit ships TortoiseGitPlink, a PuTTY derivative that expects .ppk keys loaded in Pageant and maintains its own host-key cache. Git for Windows, by contrast, typically uses its bundled OpenSSH ssh.exe, which reads keys from ~/.ssh and consults known_hosts. A local machine may also carry a GIT_SSH environment variable or a core.sshCommand override that silently masks which client is actually used, so the two environments can diverge without any visible configuration difference in the repository itself.

There is also a non-interactive concern: TortoiseGitPlink prompts to cache an unknown server host key on first connection, which cannot be answered in an unattended production session. Key-type support such as ed25519 varies by the bundled Plink version, so the deployed TortoiseGit release matters.

Given that the SSH client setting is per-installation rather than per-repository, which standardization approach is more maintainable for a mixed team: pointing TortoiseGit at ssh.exe everywhere, or keeping the PuTTY/Pageant key infrastructure?

What is the reliable way to confirm which SSH client and key store each machine is actually using before changing the setting?