[ci] run e2e tests from the runner using a remote-access kubeconfig - #1948

This reverts the remote test execution workaround from #1763 now that Holodeck can hand us a kubeconfig the runner can actually use.

Problem

#1763 was needed because Holodeck tightened the permissions on the generated kubeconfig. The file was no longer readable from the GitHub Actions runner, so the e2e tests could not reach the cluster and we moved the whole test run into the EC2 instance instead.

That workaround costs us a few things:

• the workflow writes the SSH private key to key.pem on the runner, so the secret exists as a file on disk
• Go and make have to be installed and maintained inside the instance on every run
• the source tree is rsynced into the instance, environment variables are forwarded over SSH, and logs have to be copied back afterwards

Solution

Holodeck added a kubernetes.remoteAccess option. When it is set, Holodeck rewrites the kubeconfig server URL to https://<PublicDnsName>:6443 and chowns the file to the owner of the bind-mounted workspace, so the runner user can read it. The security group still opens 6443 only to the auto-detected caller egress IP, and the file mode stays 0600.

So this PR sets remoteAccess: true in tests/e2e/infra/aws.yaml and drops the rsync/SSH scaffolding. The workflow goes back to running

make -f tests/e2e/Makefile test

on the runner, which is what it did before #1763.

The Holodeck action is already on v0.3.7 and the feature landed in v0.3.4, so no version bump is needed.

Notes

AWS_SSH_KEY is still passed to the Holodeck action, which needs it to provision the instance. Only the manual step that materialized it as key.pem is gone.

KUBECONFIG goes back to being a required environment variable in the test suite. The fallback to ~/.kube/config only made sense while the tests ran inside the instance, and in CI a silent fallback would point at the wrong cluster rather than fail.

Both LOG_ARTIFACTS and LOG_ARTIFACTS_DIR are set now. The Makefile uses the first for the ginkgo reports and the suite uses the second for its own logs, and they need to agree for the upload step to pick everything up.

The second commit removes the Archive Ginkgo logs step. It uploads ginkgo.json, which the Makefile has never written, so every run has been logging No files were found with the provided path: ginkgo.json. The reports it was meant to capture now sit under e2e_logs/, which the step above it already uploads on failure.

Validation

A full CI run passed on the first commit. Ginkgo ran from the runner workspace rather than inside the instance, and the suite reported Ran 4 of 4 Specs, 4 Passed | 0 Failed, matching the spec count on main.

Left as a follow-up: gpu-operator uses the same remote execution pattern and could be simplified the same way, but its logging and test environment differ enough to be worth a separate change.