Describe the bug

When Git LFS attempts to auto-detect the currently available and configured SSH client's "variant" type, if it does not recognize the base filename of the client's executable program it assumes the client accepts OpenSSH options.

However, under the same circumstances, recent versions of Git test the client by running the expected SSH command with the -G option, to check whether the full set of options are accepted or not. Git LFS should therefore do the same, to align with Git's behaviour and to avoid trying to use SSH clients with options they do not support.

To Reproduce
Steps to reproduce the behaviour:

# clone a repo over SSH
$ git clone git@github.com:chrisd8088/test.git
$ cd test
$ export GIT_SSH=$(command -v cat)
$ GIT_TRACE=1 git lfs fetch 2>&1 | grep "$GIT_SSH"
08:49:47.305186 trace git-lfs: run_command: /bin/cat -oControlMaster=yes -oControlPath=/tmp/sock-2671649373/lfs.sock git@github.com git-lfs-transfer chrisd8088/test.git download
08:49:47.305211 trace git-lfs: exec: /bin/cat '-oControlMaster=yes' '-oControlPath=/tmp/sock-2671649373/lfs.sock' 'git@github.com' 'git-lfs-transfer chrisd8088/test.git download'

Note the ControlMaster and ControlPath options passed to the SSH client.

Expected behaviour

Git LFS should test the unrecognized client by running the intended command with an additional -G option and then checking the command's exit code, as Git does.

System environment

The examples above were performed on macOS, but should behave the same way on any platform.

Output of git lfs env

git-lfs/3.5.1 (GitHub; darwin arm64; go 1.22.1)
git version 2.47.0

Additional context

Since commit git/git@0da0e49 in Git version 2.16.0, Git performs a check of an unrecognized SSH client by running it with the -G option. Per the git-config(5) documentation for the ssh.variant configuration option:

If the basename is unrecognized, Git will attempt to detect support of OpenSSH options by first invoking the configured SSH command with the -G (print configuration) option and will subsequently use OpenSSH options (if that is successful) or no options besides the host and remote command (if it fails).

Since commit 9ff6739 in PR #4446, when we are trying to auto-detect the variant type of an SSH client, we check whether an SSH client's executable's base filename matches either plink or tortoiseplink, and if it does not, we default to the ssh variant (i.e., an OpenSSH-compatible client) rather than the simple variant.

Note that because we default to the assumption that an unrecognized SSH client supports OpenSSH options, and our test suite sets GIT_SSH to our lfs-ssh-echo test utility program, that program receives OpenSSH connection multiplexing control socket arguments and tries to parse them. This is actually desirable, but the program should only receive these command-line arguments because it also supports the -G option, which it does not at the moment.