Research: evaluate fluxcd/flux-schema as ksail's manifest-validation engine

> 🤖 Generated by the Daily AI Engineer

**Problem.** ksail's workload validation is built on kubeconform, which has real, live pain: the `ksail workload validate` nondeterminism traces to an upstream kubeconform race (kubeconform#363, worked around via `--skip-helm-render`), its schema catalog needs external registries for CRDs, and it has no CEL evaluation — so `x-kubernetes-validations` rules (increasingly load-bearing in Flux, KRO, and Gateway API CRDs) pass validation locally and fail only on a live API server.

**What appeared upstream.** [fluxcd/flux-schema](https://github.com/fluxcd/flux-schema) (v0.10.2, active, Apache-2.0, single Go binary + Go module) is a kubeconform-inspired validator with Kubernetes API-server evaluation semantics: strict schema validation, **CEL rule evaluation with the API-server engine**, strict YAML decoding matching Flux behavior, a built-in catalog for Kubernetes/Gateway API/Flux/Flagger/Flux Operator CRDs plus the daily-rebuilt CNCF ecosystem catalog (schemas.fluxoperator.dev), CRD/OpenAPI schema extraction for custom catalogs, SOPS-aware validation, and structured JSON/YAML reports.

**Proposed direction (research spike, decision as deliverable).**
1. Map ksail's current kubeconform usage surface (validate pipeline, schema registries, flags, the #363 workaround) and its open validation pain points.
2. Prototype `flux-schema` against the same fixtures: correctness on ksail's supported distributions/CRD sets, CEL coverage, SOPS behavior, offline/air-gapped story, performance, and Go-module embeddability (library vs exec).
3. Decide: adopt as the validation engine (full swap), add alongside kubeconform (e.g. CEL-only pass), or not relevant — recorded as an ADR-style decision comment/doc, with follow-up implementation issues filed if adopted (feature-flag-first per the contract).

Also assess the side benefits while in there: whether its CEL engine can serve as the missing offline KRO RGD/CEL validation gate, and whether the platform's kubeconform-based validate lane should follow the same decision (file the platform issue separately if yes).

**Rough size.** M (research + prototype + decision; implementation is follow-up issues).

Start with `ksail workload validate` and map the existing kubeconform path, schema registries, flags, and the #363 workaround. Run flux-schema against the same fixtures and compare CEL, SOPS, offline, performance, and embedding behavior. Done means an ADR-style decision comment or document records whether to adopt, add alongside, or reject it, with follow-up issues if needed.

Written by the indexing model from the issue text.