:bug: harness git auth is HTTP basic only, so SSH-key source identities cannot clone

The harness only builds HTTP basic auth, so a Hub `source` identity that holds an SSH key cannot be
used for a run. `harness/internal/git/credentials.go:19`:

```go
func (c *Credentials) Auth() transport.AuthMethod {
if c.Username == "" && c.Token == "" {
return nil
}
return &http.BasicAuth{Username: c.Username, Password: c.Token}
}
```

There is no `ssh.PublicKeys` path, so an `ssh://` or `git@` remote gets handed basic auth and go-git
refuses it. The failure is hard to place from the outside, because the identity resolves as success
first:

```
[ok] app: coolstore (id=1), repo: git@github.com:/coolstore.git
[ok] git identity: coolstore-fork-deploy-key
[header] Git Setup
cloning git@github.com:/coolstore.git...
Error: clone: clone git@github.com:/coolstore.git: invalid auth method
```

Hub accepts the key happily, and I think other consumers of the same identity kind do use SSH keys
(I have not checked the analyzer path), so a user with an SSH-only git server gets a green identity
and a clone that cannot work. Either add an SSH auth path, or reject an SSH key at resolution time
and say so, rather than logging `[ok] git identity` and failing later.

Start at harness/internal/git/credentials.go:19 and trace how Credentials.Auth is selected for Hub source identities and passed to go-git during cloning. Reproduce the failure with the SSH remote shown in the issue, then verify that SSH-key identities no longer reach an invalid basic-auth clone, either by working through the clone or by receiving a clear resolution-time rejection.

Written by the indexing model from the issue text.