Every KSail-managed platform component stays overridable and extensible via GitOps, and survives reconcile and upgrade

> 🤖 Generated by the Agentic Engineer

Part of #6875. Implements the contract decided in #6876.

## Why this is not optional

Maintainer direction 2026-09-04 pairs two requirements that pull against each other: the platform
config is **built into KSail and requires no hand-written GitOps repository**, *and* users must be able
to **extend or override every KSail-managed component and configuration via GitOps**, so it is always
possible to configure it further.

Built-in defaults without an escape hatch is the failure mode that makes people fork. The moment an
adopter needs one annotation KSail does not expose, a platform they cannot override becomes a platform
they must abandon — and everything #6875 promises about saving years is lost at exactly the point they
start doing real work.

So this is the child that decides whether the epic is adoptable, not a convenience layer on top of it.

## What it must support

- **Override** a value inside a component KSail manages, without taking ownership of the whole
component.
- **Extend** the platform with resources KSail knows nothing about, alongside managed ones.
- **Take full ownership** of a component — stop KSail managing it — without abandoning the rest of the
platform.
- **Survive reconcile.** An override is not a race with KSail's own reconciliation. Whatever the
precedence rules from #6876 say, the observed behaviour must match them.
- **Survive upgrade.** A KSail version bump that changes a component's built-in defaults must not
silently discard an adopter's override, and where it conflicts, must surface it rather than pick.

## Acceptance criteria

- [ ] Each of the four operations above is demonstrated end-to-end against a real cluster.
- [ ] An override applied via GitOps is still in effect after a KSail reconcile — asserted by reading
the live resource back, not inferred from the render.
- [ ] An override that conflicts with a changed built-in default on upgrade is surfaced, with a
documented resolution path.
- [ ] Taking ownership of one component leaves the remaining managed components working.
- [ ] Behaviour matches the precedence rules recorded in #6876; any divergence is a defect in one of
the two.
- [ ] Documented with a worked example for each operation.

## Verification note

This is behavioural, so static validation cannot establish it. Every criterion above needs the real
effect observed — the rendered manifest agreeing is necessary and not sufficient, because the failure
mode here is precisely that reconciliation overwrites what the render showed.

## Size

Large. Worth splitting per operation once #6876 lands.

Start by reading the precedence rules in #6876 and the parent scope in #6875 before splitting this large issue by operation. Validate each override, extension, ownership transfer, reconcile, and upgrade scenario against a real cluster, checking live resources rather than rendered manifests. Done means all acceptance criteria pass and each operation has a documented worked example.

Written by the indexing model from the issue text.