EKS ownership state has no supported recovery path

> 🤖 Generated by the Agentic Engineer

## Problem

KSail keeps two independent records of an EKS cluster's identity, and the lifecycle guard reads one while the only repair command writes the other. An operator whose local state is lost has no supported way back.

- `confirmEKSOwnership` (the delete/start/stop guard) reads the create-time cluster spec via `state.LoadClusterSpec`.
- `ksail cluster eks-bind` writes the region-scoped immutable-identity record via `eksidentity.Persist` → `state.SaveEKSOwnershipState`.

They are different files. `eks-bind` therefore cannot clear the guard's refusal, and nothing else rebuilds the create-time record for a cluster KSail did not create. The guidance now says so honestly and points at the AWS tooling (#6385), but that is an accurate dead end, not a recovery path.

## Why it matters

Losing local state is an ordinary occurrence — a new machine, a wiped home directory, a colleague taking over. Today that means the cluster is permanently unmanageable through KSail: every mutating path refuses, and the operator must fall back to `eksctl` for the rest of the cluster's life.

## Direction

Codex framed the choice well when it found this: either the recovery path creates the files the backend consumes, or the backend consumes the record `eks-bind` actually writes. The second is the more attractive shape — one identity record, one repair command — but it is not a patch:

- `LoadEKSOwnershipState` is region-scoped, and the region comes from the `eks.yaml` that is missing in exactly this scenario. Resolving the region without it is the core of the design.
- `confirmEKSOwnership` deliberately does not promote persisted state to the runtime target (it is a sanitized snapshot with credentials redacted), so any unification has to keep that boundary.

A spike that decides between the two, and states how the region is resolved, is the right first step.

## Acceptance criteria

- A decision is recorded (ADR under `docs/adr/`) for one of the two directions, naming how the region is resolved when `eks.yaml` is absent.
- An operator who has lost local state has one documented, supported command that makes a previously-created EKS cluster manageable again.
- The redaction boundary is preserved: recovered state must not replay sanitized values as a runtime target.
- The guard still refuses a genuinely unconfirmable target — the negative control in `TestDeleteEKSRefusesLiveClusterWithoutOwnershipState` keeps passing.

Found while fixing #6385; that PR corrects the misleading guidance but deliberately does not attempt this.

Read confirmEKSOwnership, state.LoadClusterSpec, eksidentity.Persist, state.SaveEKSOwnershipState, and LoadEKSOwnershipState to compare the records and determine how region resolution works without eks.yaml. Record the choice and region strategy in docs/adr/, then trace the supported recovery command while preserving the redaction boundary. Run TestDeleteEKSRefusesLiveClusterWithoutOwnershipState as the negative control.

Written by the indexing model from the issue text.