Local API EKS verification ignores the credential names its ownership record was captured under

> 🤖 Generated by the Agentic Engineer

## Evidence

Found while fixing #6443 on #6434, and confirmed against the code.

Once #6434 lands, the ownership **record** carries the AWS variable names the create resolved through — `credentials.AWSOptionsWithDefaults(identity.awsOptions)`, taken from `spec.provider.aws`. The **verification** path in the same package still resolves independently from the ambient resolver:

- `defaultEKSGuard` → `eksIdentityClient(ctx, region)` → `credentials.ResolveAWS(s.discoverer.Resolver)` (`pkg/cli/clusterapi/eks_ownership.go`), which reads the canonical `AWS_*` names.

The standalone CLI path does honour the persisted names — `restorePersistedAWSOptions` merges `ownership.AWSOptions` back in before resolving (`pkg/cli/cmd/cluster/unmanaged_guard.go:365-436`). The local API backend has no equivalent step.

## Affected audience and impact

Operators who set custom `spec.provider.aws` variable names and drive EKS lifecycle actions from the local web UI.

**This fails closed, so it is not a second instance of #6443's fail-open.** Verification queries whichever account the ambient credentials name: it either finds nothing (refused) or finds a different incarnation whose identity does not match the record (refused). The cost is availability, not safety — a cluster created under custom variable names cannot be deleted, started or stopped through the local API unless the canonical `AWS_*` environment happens to point at the same account.

That is the failure mode `captureEKSOwnership`'s own doc comment calls out as the thing to avoid: "a guard that blocks the path it is meant to protect".

## Expected behaviour

A guarded lifecycle action resolves AWS through the variable names recorded on the ownership state for that cluster, falling back to the ambient resolver only when the record carries none — mirroring `restorePersistedAWSOptions`.

## Acceptance criteria

- [ ] `defaultEKSGuard` resolves credentials through the persisted `ownership.AWSOptions` when present.
- [ ] A cluster captured under custom variable names verifies successfully when only those custom variables are set, with the canonical `AWS_*` names unset or pointing elsewhere.
- [ ] Control: a record carrying no options (or the canonical defaults) keeps resolving exactly as it does today — the default path must not change.
- [ ] Ablation: reverting the resolution to the ambient resolver turns the first test red and leaves the control green.

## Size

Small. One resolution site plus tests; the CLI path already demonstrates the shape.

Start in pkg/cli/clusterapi/eks_ownership.go at defaultEKSGuard and compare its credential resolution with restorePersistedAWSOptions in pkg/cli/cmd/cluster/unmanaged_guard.go:365-436. Add focused coverage for custom persisted names and the no-options or canonical-default control; done means custom credentials verify successfully while the default path remains unchanged.

Written by the indexing model from the issue text.