[E7-T2] Implement idempotent agenova platform plan/apply

## Outcome

`agenova platform plan/apply -f platform.yaml` validates and idempotently reconciles one complete Agenova Platform desired state on an explicitly selected existing target.

## Delivery contract

- **Parent Epic:** #11 (E7)
- **Size:** M
- **Depends on:** #40, #44, #151
- **Wave:** Wave C - Credible delivery
- **Sequence:** 702
- **Planning depth:** Task + Spec + Design

## Product behavior

`platform apply` is the primary non-interactive entry point. It resolves and activates missing adapter requirements through the same adapter lifecycle service, validates every named instance through its adapter, computes an inspectable plan, obtains confirmation unless `--yes` is supplied, and then reconciles infrastructure and implemented services in dependency order.

`agenova adapters install/init` remain lower-level controls. `agenova bootstrap` is a later guided producer of the same Platform YAML and invokes the same plan/apply services; neither creates another installer.

The deployment adapter interprets how Agenova is installed/started on the selected target. RuntimeBackend and service adapters remain independently selected; using Kubernetes to host Agenova does not force every worker or model integration to use Kubernetes.

## Acceptance criteria

- `validate` and `plan` perform complete generic and adapter-owned validation with no target mutation and stable human/JSON output.
- First apply reaches the reference Ready state; a second identical apply reports no changes and creates no additional named resources.
- Missing adapter implementations are resolved/activated through the shared registry. Unknown identity/version, wrong capability, malformed config, insufficient authority/RBAC, wrong target and missing prerequisite fail before partial success where possible and always produce actionable diagnostics.
- Reconciliation records the effective Platform revision and adapter lock/state without secrets. Existing active claims are not rebound or expanded by a later apply.
- The reference implementation targets an existing Kubernetes cluster and uses current credentials/RBAC; there are no root `--kube-context` or `--namespace` product flags. Those values live only in the selected deployment/runtime adapter config.
- The applied Platform exposes enough read-only status for CLI/UI to distinguish configured, available, used and failed components without leaking private adapter config.
- A compiled CLI performs the workflow without `go run` or hand-written orchestration scripts; scripts remain test harnesses only.

## Quality gate and evidence

- Plan/first apply/idempotent second apply and denied-RBAC transcripts on the reference target.
- Adapter test doubles prove deployment, runtime and services can be selected independently without command-layer branches.
- Failure-injection evidence for validation and bounded partial reconciliation; focused tests and `./scripts/check.ps1 -All`.

## Non-goals

Creating a cluster; production upgrades/rollback/HA; arbitrary external plugin loading; implementing not-yet-supported tool/memory/observability providers; Policy CRUD; AgentTemplate management.

## Definition of Done

- Acceptance behavior and its named negative cases are observable.
- Focused checks and the repository baseline pass, or an explicit blocker is recorded.
- A teammate can reproduce the evidence.
- The change remains inside the parent Epic and architecture boundary.