fix(operator): report missing gateway CRDs instead of claiming Ready

[dcmcand]

The bug

An LLMModel whose AIGatewayRoute, SecurityPolicy or InferencePool could not be applied reported phase Ready with nothing to indicate a problem. The reconciler knew perfectly well - llmmodel_controller.go:455 before this change:

if err := r.createOrUpdateUnstructured(ctx, routing.ExternalRoute); err != nil {
    log.Error(err, "failed to reconcile external AIGatewayRoute - CRD may not be installed, skipping")
}

reconcileRoutingResources then returned nil unconditionally (//nolint:unparam // error return kept for future extensibility), same for reconcileSecurityPolicies and the InferencePool apply. So the operator log was the only trace, and the visible symptom was an HTTP 404 or 500 at request time against a healthy-looking model with nothing in ArgoCD to explain it. This is the failure mode that makes the install runbook's §4 prerequisites so costly to skip.

The fix already existed next door

passthroughmodel_controller.go:130 solved this, and its comment named the culprit:

// Gateway kinds tolerate a missing CRD: a failed apply does not fail the whole reconcile. Unlike the LLMModel reconciler (which only logs and moves on), each failure is captured in a status condition and the reconcile is requeued...

So this ports that pattern rather than inventing one.

• Both reconcile functions return per-endpoint outcomes; reconcileInferencePoolResources returns the pool apply error separately from failures in resources this pack does own (those stay fatal).
• One condition per endpoint, covering its route and its policy together - they fail for the same reason and are fixed by the same action, so splitting them is noise.
• InferencePoolReady is its own condition, because it comes from a different CRD bundle. A cluster can have the AI Gateway CRDs but not the Inference Extension's, and that combination crashloops the llm-d EPP while routing looks fine. Diagnosing that needs the two told apart.
• Ready degrades to Degraded on a failed apply. The workload is healthy but unreachable, which is what Degraded describes; Error would overstate it. Pending/Downloading/Starting already say something more specific and are untouched.
• Requeued so the model heals once the CRDs appear, instead of sitting Degraded until something else triggers a reconcile.

A missing CRD still does not fail the reconcile - everything the pack owns is worth converging.

conditionFor, disabledCondition and the condition constants move to a new conditions.go now that both controllers use them, and PassthroughModel's phase check uses the shared hasApplyFailure instead of re-deriving it from a "ApplyFailed" string literal.

⚠️ Behavior change

A model with broken routing that previously reported Ready now reports Degraded. That's the point, but it will move dashboards and can fire alert rules keyed on phase. New conditions are purely additive.

Verification

• go test ./... green, including 15 envtest specs; golangci-lint run → 0 issues; go vet and gofmt clean
• Table-driven tests for the pure helpers (conditionFor, hasApplyFailure, phaseWithRoutingFailure), including that a disabled endpoint is False but must not count as a failure
• envtest specs pin the user-visible behavior. envtest installs only this operator's CRDs, so the gateway applies fail with no-kind-match exactly as on a cluster where §4 was skipped - the test timeline shows the real error: no matches for kind "InferencePool" in version "inference.networking.k8s.io/v1". The specs first reconcile, then set the Deployment's readyReplicas by hand, because nothing runs the Deployment controller in envtest and determinePhase would otherwise return Starting and short-circuit before any gateway resource is applied.
• Both new specs are mutation-verified, so they cannot pass vacuously:
  • disable the phase downgrade → unit test fails (= "Ready", want "Degraded") and the envtest spec fails
  • restore the swallowed poolErr → the envtest spec fails on the InferencePool condition

Follow-up

A troubleshooting entry pointing at these conditions belongs in installation.md, but that file is being rewritten in #171 and #172. Left out here to avoid the conflict; worth adding once those land.