Hosted operator: reconcile a declared platform, so KSail can provision and manage platforms centrally

> 🤖 Generated by the Agentic Engineer

Part of #6875. Later phase — depends on the slot substrate existing.

## Direction

Maintainer direction 2026-09-04, clarifying #6875: as a **hosted operator**, KSail additionally becomes
*a platform to provision platforms* — while remaining a CLI, a desktop app and a web UI. This child
covers that hosted dimension only; it removes nothing from the other interfaces.

## Why this is a natural extension rather than a new product

`ksail-operator` already exists and runs in the reference platform, and #4899 is already building
per-component lifecycle management inside it. Once #6875 makes a platform expressible as slots and
presets in configuration, the remaining step is to let that configuration be reconciled by an operator
rather than applied by a CLI invocation — the same declarative content, a different actuator.

That is what turns *platforms as a product* into something an organisation runs centrally: a team
declares the platform it wants, and a hosted control plane provisions and continuously reconciles it.

## Scope

- A cluster-scoped resource expressing a desired platform — the same slots and presets the CLI accepts.
- Reconciliation of that resource: provision, converge, and report status per capability.
- Multi-target provisioning: one control plane managing platforms across more than one cluster.
- Honest status, per capability, distinguishing *not requested*, *converging*, *ready* and *failed* —
and never reporting ready for a capability it has not observed working.

## Deliberately deferred

Tenancy, authorization and quota for a hosted control plane are their own problem and should not be
smuggled in here. Scope them separately once the reconciliation shape is proven — the boundary with
`platform-tenant-template` needs deciding rather than assuming.

## Acceptance criteria

- [ ] A platform resource expresses the same slot and preset selections the CLI supports, with no
divergent second schema.
- [ ] Applying it to a cluster provisions the platform and reports per-capability status.
- [ ] Changing a slot converges the running platform rather than requiring a rebuild.
- [ ] Removing a capability removes what it installed, without stranding resources.
- [ ] Status reflects observed reality — a capability reports ready only when its behaviour has been
seen working, not when its manifests were applied.
- [ ] GitOps override (#6878) still holds for operator-provisioned platforms; the actuator changing
does not change the escape hatch.
- [ ] Feature-flagged, default-off, tested in both states.

## Dependencies

Needs #6876, and realistically #6879 and #6880 shipped first — reconciling a platform is only
meaningful once there is a platform worth reconciling. Builds on #4899.

## Size

Extra large — deliver after the CLI path is proven, and split before starting.

Start by reading the dependency issues #6875, #6876, #6878, #6879, #6880 and the existing lifecycle work in #4899; no files, tests, or entry points are named here. Before implementation, split the extra-large scope into deliverable pieces. Done means a feature-flagged operator resource can provision and reconcile declared platforms across clusters, report observed per-capability status, preserve GitOps overrides, and clean up removed capabilities.

Written by the indexing model from the issue text.