Switching TortoiseGit from TortoiseGitPlink to Git's ssh.exe: what key and host-key configuration must move with it

Goal

Our team standardizes developer machines on TortoiseGit over Windows. Repositories authenticate to our Git server over SSH, and the setup works on every interactive desktop where Pageant holds a PuTTY-format .ppk key. The same repositories fail authentication when cloned from a Windows service account on a build machine, and we are considering changing Settings > Network > SSH client from the bundled TortoiseGitPlink to Git's ssh.exe (OpenSSH) so both contexts behave identically.

Constraints and uncertainty

My understanding is that TortoiseGitPlink reads keys from Pageant or a per-remote Putty key setting, and ignores ~/.ssh/config and OpenSSH-format keys, while ssh.exe honors ~/.ssh/config, id_* key files, and its own known_hosts. Switching the client therefore seems to change which key files, host-key stores, and per-remote overrides apply, and the build account cannot see the interactive user's Pageant session anyway.

What is unclear is the full migration surface: whether existing per-remote Putty key settings are silently ignored after the switch, whether cached host keys in the PuTTY registry need to be re-established for OpenSSH, and whether GIT_SSH or a system OpenSSH install can still override the settings dialog.

Questions

1. After switching the SSH client to ssh.exe, do per-remote Putty key entries stop applying, and must keys be re-specified via ~/.ssh/config per host?
2. How should host keys be pre-cached for the service account so non-interactive pulls are not blocked by a first-connection prompt?
3. Is there a supported way to confirm at runtime which SSH client binary TortoiseGit actually invoked?

Assume a current TortoiseGit 2.x release; exact menu labels to be verified against the installed version.