Derive the platform capability inventory from the reference platform, with a verdict and a justified default per capability

> 🤖 Generated by the Agentic Engineer

Part of #6875. Depends on the schema decision in #6876 only for *how* the inventory is expressed — the
inventory itself can be derived in parallel.

## Problem

#6875 names `devantler-tech/platform` as the continuous reference target for what a production-ready
platform contains, but "what it contains" is currently a directory listing, not a decision. Roughly 30
components run there, and they are not all the same kind of thing: some are platform capabilities any
adopter needs, some are opinionated choices worth defaulting to, and some are specific to that
deployment and must never become a KSail default.

Shipping the list as-is would hard-code one operator's preferences into a product. Shipping nothing
leaves every adopter to rediscover the same 30 decisions.

## What this child produces

A reviewed inventory that assigns **every** component in the reference platform exactly one verdict:

| Verdict | Meaning |
|---|---|
| **Slot** | A capability adopters generally need. Becomes a selectable slot with an opinionated default. |
| **Default-only** | Needed, but with no realistic alternative worth exposing. Provisioned without a choice. |
| **Deployment-specific** | Real for the reference platform, wrong as a KSail default. Stays consumer-side, reachable via the GitOps extension path. |
| **Out of scope** | KSail should not provision this at all. Record why, so it is not re-litigated. |

For every **Slot**, also record: the default implementation and *why it is the best-practice default*,
the realistic alternatives worth supporting, and its dependencies on other slots.

## Starting evidence

Components observed in the reference platform (2026-09-04): auth-proxy, cdi, cert-manager, chaos-mesh,
cilium, cloudnative-pg, coredns, coroot, dex, external-secrets, flagger, flux-operator, keda, kro,
ksail-operator, kubescape, kubevirt, metrics-server, oauth2-proxy, openbao, openfeature-operator,
plugin-barman-cloud, reloader, tetragon, trust-manager, velero, vertical-pod-autoscaler — plus the
cross-cutting wiring: cluster-policies, cluster-role-bindings, cluster-roles, cluster-secret-stores,
cluster-security-exceptions, gateway, opencost, policy-reporter, audit-log-forwarder, tracing-policies,
resource-graph-definitions, vault-config/vault-seed/vault-backup.

**Re-derive this list rather than trusting it** — the reference platform is a moving target, which is
the point of it being *continuous*.

## The wiring question

The cross-cutting items above are what make the components a platform rather than a pile of charts.
Decide explicitly whether each is generated by KSail, is a consequence of slot selection, or is left to
the adopter. A platform that installs 30 operators and wires none of them together has not saved
anyone years.

## Acceptance criteria

- [ ] Every component and wiring concern above carries exactly one verdict, with reasoning.
- [ ] Each Slot names its default, that default's justification, and its realistic alternatives.
- [ ] Slot dependencies are recorded as a graph, not prose.
- [ ] The inventory is expressed in a form the schema work (#6876) can consume directly.
- [ ] Anything ruled Deployment-specific or Out of scope says what an adopter does instead.

## Size

Medium-to-large — the judgement is the work, not the typing.

Start by re-deriving the component and wiring list from the continuous reference platform described in #6875, then review the schema decision in #6876. Classify every component and wiring concern with one verdict and record the requested defaults, alternatives, justifications, dependencies, and adopter actions. Done means the reviewed inventory is expressed in a form that #6876 can consume directly.

Written by the indexing model from the issue text.