Gate SkillCollection / run readiness on the SkillCard Resolvable condition

### Background

#188 added a best-effort `Resolvable` condition to image-backed SkillCards
(`ArtifactPresent` / `ArtifactMissing` / `ResolveInconclusive`) so a phantom
image ref — well-formed, `Ready=True`, but with no manifest in its registry — is
surfaced before run time, which is the point of #187.

Today that condition is **informational only**. Nothing consumes it, so it does
not yet prevent the failure #187 set out to catch.

### Problem

`SkillCollection.checkSkillCardRef`
([skillcollection_controller.go:174](https://github.com/konveyor/agentic-controller/blob/main/internal/controller/skillcollection_controller.go#L174))
gates a collection's readiness only on the card's `Ready` condition. So a phantom
card (`Ready=True, Resolvable=False`) still makes its collection `Ready`, and a
run using that collection is still admitted — then `ImagePullBackOff`s at pod
time. The same is true for an AgentRun that references a phantom card directly.

### Proposal

Decide how `Resolvable` should feed collection and run admission. Two design
calls to settle:

1. **What may block — only `False`, never `Unknown`.** `Resolvable=Unknown` is
best-effort inconclusive (a private registry the controller can't
authenticate to, or a transient network error); the pod may still pull it
with its own `imagePullSecrets`. Gating on `Unknown` would break every
private image, so only a definitive `Resolvable=False` is a candidate to
block.

2. **Hard gate vs. soft warning.** Does `False` make the collection `NotReady` /
refuse the run (a real run-admission gate), or just annotate a warning and
let the operator's requested run proceed? A hard gate changes admission
semantics.

### Caveat to resolve before any hard gate

`classifyResolveError`
([imageresolve.go](https://github.com/konveyor/agentic-controller/blob/main/internal/controller/imageresolve.go))
currently maps a **bare 404** (no `MANIFEST_UNKNOWN` / `NAME_UNKNOWN` code) to
`Missing`. Some registries answer 404 for private repos to avoid leaking
existence, so a pullable private image could report `Resolvable=False`. If
`False` becomes a hard gate, tighten the classification first (only the
structured codes → `Missing`; a code-less 404 → `Unknown`) or the gate will
wrongly block private images.

---

Follow-up to #187 / #188 (per @djzager's review). Filing to capture the design
so the new condition doesn't stay inert.

Start with SkillCollection.checkSkillCardRef in internal/controller/skillcollection_controller.go and classifyResolveError in internal/controller/imageresolve.go. Read the related readiness and AgentRun admission paths, then settle how Resolvable=False and Unknown should be handled, including the bare-404 caveat. Done means the admission behavior is decided and covered by appropriate controller tests.

Written by the indexing model from the issue text.