Let an existing cluster provide the serving stack itself

[haarchri]

Description of your changes

An existing cluster often already runs cert-manager, kube-prometheus-stack and a gateway stack. Modelplane installed its own copies anyway, so the installs fought over cluster-scoped CRDs and the only way out was taking the break-glass Composition.

This adds an all-or-nothing Provided mode. With spec.cluster.existing.components: Provided Modelplane installs no substrate at all. Every serving stack component now carries a role:
substrate, or Modelplane's own configuration and each substrate entry states what a provided cluster must supply in its place: the APIs to check, the expectations nothing can check (controller wiring, GPU drivers), and what users can skip. The checks render as observe-only provider-kubernetes Objects on the target cluster, and a RequirementsMet condition on the ServingStack, mirrored onto the InferenceCluster, names exactly what is missing instead of failing later with an unclear error.

Modelplane's own configuration (the gateway pair and its PKI, the KAI Queues, ModelExpress) still composes, with each substrate depends_on edge gated on the checks standing in for it, so nothing is applied into a cluster whose API can't accept it. Unmet requirements block only their dependents and keep the ServingStack unready; everything satisfiable reconciles, so an admin watches the checks go green one by one. On teardown Modelplane cannot hold a substrate it does not own, so finalizers on its configuration rely on the user keeping their controllers running.

The field is immutable, like spec.stack: flipping a live cluster from Managed to Provided would uninstall its substrate.

Before:

    spec:
      cluster:
        source: Existing
        existing:
          secretRef: {name: byo-kubeconfig}

After, on a cluster that already runs the substrate:

    spec:
      cluster:
        source: Existing
        existing:
          components: Provided
          secretRef: {name: byo-kubeconfig}

What the platform owner sees while the cluster falls short:

    - type: RequirementsMet
      status: "False"
      reason: MissingRequirements
      message: 'The cluster is missing: kube-prometheus-stack (API v1.monitoring.coreos.com not served)'

Validated end to end with nix run .#e2e -- --provided --verify (CI label test-e2e-provided): the substrate is pre-installed from the generated inputs under non-mp- release names with kube-prometheus-stack held back, and the run asserts RequirementsMet names it, flips to True once it installs, that the serving stack composed no Helm release of its own, and that a live request returns 200.

Fixes #436

I have:

• Read and followed Modelplane's contribution process.
• Run nix flake check (or ./nix.sh flake check) and made sure it passes.
• Added or updated tests covering any composition function changes.
• Signed off every commit with git commit -s.

[github-actions]

Docs preview: https://modelplane-docs-pr-488.vercel.app (ready once the site's Content workflow finishes)