Link SSH fingerprints to Git Proxy users

A follow-on from https://github.com/finos/git-proxy/pull/1604, use SCM's [well known endpoint to view a given user's SSH key fingerprints](https://docs.github.com/en/rest/users/keys?apiVersion=2026-03-10#list-public-keys-for-a-user), list key fingerprints of all known SCM users that GitProxy is aware of (it was `gitAccount` but that field is likely to be reworked and revisited as per @kriswest comment below) and carry that link of GitProxy-user-to-SCM-user internally for SSH pushes.

**Why this is important?**

SSH support today trusts a set of registered public keys, but the association between a key and an SCM identity is self-asserted and unverified. Any authorization decision rests on a key->identity link that may be wrong. For example:

- Alice has a git-proxy account and her own SSH key `bar` (she legitimately holds the private key). The key grants some permission to an upstream like github.com/baz/repo.
- Nothing today stops `bar` from being linked to `thomascooper-github` - the GitProxy user -> SCM user mapping is asserted, not checked against the SCM.
- Alice's pushes are then linked to, and authorized as, Thomas.
- Building the link from the SCM's published keys closes this: `bar` is not among the keys published under `thomascooper-github`, so the association is rejected. A user can only be linked to an SCM identity whose published keys include the key they're connecting with.

This would be the SSH counterpart to the token (HTTP `Authorization` header) -> user linkage in #1604.

This allows for GitProxy to associate a key with a known SCM identity in addition to the GitProxy internal user registration of SSH public keys. Both GitHub and GitLab expose unauthenticated endpoints to do this lookup for a given public user.

```
$ curl https://api.github.com/users/coopernetes/keys
[
{
"id": 90942779,
"key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKz6e608fCNeq1/Qi3NRacRm44ax05XhVNeahiRi9/HE",
"created_at": "2023-11-22T02:38:13Z",
"last_used": "2026-07-15T03:58:16Z"
}
]
```

Note, I discovered that Forgejo & Gitea instances do not provide this endpoint without authentication. Either an OAuth app or a GitProxy owned token is required to hit the equivalent API for that SCM provider.

Start by reviewing the token-to-user linkage work in pull request #1604, the current GitProxy user field mentioned in the issue, and the SSH push flow. Compare the GitHub and GitLab public-key endpoints, noting the authenticated Forgejo and Gitea limitation. Done means an SCM identity is accepted only when its published keys include the linked SSH key and the mapping is carried through SSH pushes.

Written by the indexing model from the issue text.