ci: force VM harness clone to use deploy key

[mgmobrien]

Summary

• fix the first real merge-hsm E2E standard suite failure after PR ci: rename e2e workflow to standard suite #81 merged
• stop relying on stale VM ~/.ssh/config when cloning or updating the private relay-harness repo
• force the VM-side harness git operations to use the staged ci-deploy-key via GIT_SSH_COMMAND

Root cause

The Linux VM already has ~/.ssh/config pinned to ~/.ssh/relay-e2e-deploy, and that key does not have access to No-Instructions/relay-harness. The workflow was appending a second Host github.com stanza, but that was not a reliable override, so the private harness clone failed inside the VM step.

Verification

• git diff --check -- .github/workflows/e2e-standard.yml
• ruby -e 'require "yaml"; YAML.load_file(".github/workflows/e2e-standard.yml")'
• direct VM repro of the stale-key failure mode via gcloud ssh

[mgmobrien]

@dtkav follow-up to #81. The first real merge-hsm standard-suite run failed because the Linux VM still had a stale github.com SSH identity pinned in ~/.ssh/config, so the private harness clone used the wrong key. This PR forces the VM-side harness git ops to use ci-deploy-key explicitly.

[dtkav]

probably should put the github host keys in:

https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints

[dtkav]

IdentitiesOnly yes could also be applied to the old way (so it isn't per session), but this way is fine too.