Support private git repos and authenticated images as skill sources

`SkillCard.spec.source` clones unauthenticated, so a private repo cannot be a
skill source. Fine for ours, which are public, and blocking for anyone wanting
to keep an internal skill internal, which is most of the reason to use a git
source rather than publishing an image.

The mechanism exists. `harness/internal/git/credentials.go` has
`Credentials{Username, Token, RepoURL, Branch}` with an `Auth()` that the
workspace clone uses, and the loader just does not use it.

The question is whose credentials those are. I lean toward a secret ref on the
SkillCard rather than reusing the workspace token, since the skill source and
the application repo are not necessarily the same tenant. Reusing it would hand
the skill publisher's repo access to anyone who can create an AgentRun, and
would stop a skill source being usable by a run whose application lives
somewhere else. Worth arguing about first, since it is a CRD field either way.

Private images are smaller but belong in the same pass. An ImageVolume pulls
with the pod's `imagePullSecrets`, so a private skill image works today if the
namespace happens to be set up for it. That is undocumented and untested, and
it fails as a pod that will not start with a message about the image rather
than about the skill.

- [ ] decide: secret ref on the SkillCard, or reuse the workspace credentials
- [ ] plumb credentials into the loader's clone
- [ ] document how a private skill image is pulled, and fail readably when it cannot be
- [ ] keep credentials out of the assembled skills root. The loader already excludes `.git` for this reason, since a tokenized clone URL ends up in `.git/config`