Poor SSH key handling: overly coupled to `id_rsa` private keys

Describe the bug

The Lagoon CLI tool seems to make several assumptions about SSH keys. In several places, the existing code searches for exactly the string ~/.ssh/id_rsa, giving that type of private key special status. GitHub specifically recommends ed25519 keys and only suggests RSA on "legacy systems".

In PR https://github.com/uselagoon/lagoon-cli/pull/44, it was suggested by @smlx:

Honestly I think it would be fair to offload all key handling to the agent and not attempt to manually load SSH keyfiles at all. Best practice is to use an agent anyway, and that way any new SSH key formats are automatically handled going forward.

But I don't think this suggestion was implemented.

It would be much better if Lagoon CLI would read (and try) all available keys from ssh-add -L, rather than reading individual SSH keys.

To Reproduce
Steps to reproduce the behavior:

1. Install lagoon CLI normally.
2. On an environment where ~/.lagoon.yml has not been modified to add an sshkey value, create a key at ~/.ssh/id_ed25519 with chmod 600. There should also not be a ~/.ssh/id_rsa file.
3. Attempt to execute a lagoon command such as lagoon whoami
4. The command will return Error: open /home/runner/.ssh/id_rsa: no such file or directory.

Expected behavior
The command should succeed using the available ~/.ssh/id_ed25519 key.

Desktop (please complete the following information):

• OS: Ubuntu 24.04

Start with the code path used by lagoon whoami and the existing handling of ~/.ssh/id_rsa; review the prior discussion in PR #44. Check how ssh-add -L relates to the available keys, then verify that an environment with only ~/.ssh/id_ed25519 allows the command to succeed without an id_rsa file.