Guard local API EKS lifecycle targets with persisted ownership

[devantler]

🤖 Generated by the Daily AI Engineer

Evidence

The local web/API backend exposes EKS create, delete, start, and stop, but its lifecycle target is not bound across requests:

• EKS create renders ~/.ksail/clusters//eks.yaml from the AWS region currently selected in Settings.
• After a successful create, runCreate marks the job ready but does not persist the EKS/AWS cluster intent used by standalone lifecycle ownership checks.
• Delete, start, and stop rediscover the cluster, rebuild the provisioner, and regenerate the EKS config from the region selected at action time. They do not apply the CLI's exact name/region/local-ownership guard.
• A successful API delete does not clean persisted cluster state or the generated EKS config.

Changing Settings between creation and a later lifecycle action can therefore redirect the action to a same-named cluster in another region. A cluster created through the UI also lacks the state needed for a later standalone CLI action from a normal working directory.

Related to #6087 and the stronger immutable AWS identity binding tracked in #6202.

Affected audience and impact

Users who create or operate EKS clusters through the local web UI/API can have a lifecycle action rejected later by the CLI or, in the worst case, applied to an accessible same-named cluster in the wrong AWS region. Delete is destructive, so the backend must fail closed when target identity is missing or inconsistent.

Expected behavior

The local API must preserve the exact EKS target established at creation and apply the same fail-closed ownership checks as standalone CLI lifecycle commands. Ambient or newly selected AWS settings must not silently rewrite an existing cluster's mutation target.

Acceptance criteria

• A successful local API EKS create persists target-bound KSail ownership state, including the original name, distribution, provider, and creation region; align immutable account/cluster identity with Bind EKS lifecycle ownership to immutable AWS identity #6202.
• EKS delete, start, and stop load that target-bound state and refuse mutation when it is absent, ambiguous, or inconsistent.
• Every EKS mutation performs an exact read-only ownership query for the bound name and region before invoking delete or nodegroup scaling.
• Changing the AWS region in Settings after creation cannot redirect a lifecycle action or overwrite the original target evidence.
• Successful and idempotent deletion safely remove the matching state and generated config without touching unrelated targets.
• Tests cover creation-to-lifecycle state reuse, changed Settings, missing/mismatched state, same-name clusters in different regions, cleanup, and a local API user-flow exercise.

Rough size

Medium: shared ownership/state integration plus local API lifecycle tests; coordinate the immutable identity shape with #6202.