fix(clusterapi): carry the ownership record's AWS credential mapping through to the EKS provisioner

[devantler]

🤖 Generated by the Agentic Engineer

Evidence

Raised by Codex against #6385 and confirmed structurally at ac74b807:

• bindFromOwnershipRecord (pkg/cli/clusterapi/distconfig.go) reads the ownership record and keeps
  ownerships[0].Region only.
• The EKSConfig it returns (pkg/svc/provisioner/cluster/factory.go) has fields for Name,
  Region, ConfigPath and KubeconfigPath — and nowhere to put AWSOptions.
• AWSOptions / OptionsAWS / Provider.AWS appear nowhere in pkg/cli/clusterapi/ outside
  tests, at origin/main as well as on the fix(clusterapi): bind local API EKS lifecycle actions to the creating region #6385 branch (checked with git grep at both revisions).

eksidentity.Capture requires a complete AWSOptions mapping precisely so that an operator running a
cluster through custom credential variables cannot silently persist canonical names and later resolve
a different ambient identity. ListEKSOwnershipStates likewise only accepts records carrying a
complete mapping. That care is then discarded at the point of use.

Problem

The credential mapping recorded at bind time is dropped, and resolution falls back to the canonical
AWS_* variables. That is the "same cluster name in another account" hazard arriving through the
credential resolver instead of through the region — the same class of redirect #6385 closes for the
region axis, still open on the account axis.

Scope note

This is not a regression introduced by #6385: the credential axis was equally unbound before it
(verified at origin/main by the grep above). #6385 closes the region axis and leaves this one as it
found it. Recording it here so the remaining gap is tracked rather than implied.

Proposed direction

Widen EKSConfig with the options mapping (additive — the zero value preserves today's behaviour at
all eight construction sites), populate it from the record in bindFromOwnershipRecord, and make the
EKS provisioner resolve credentials through it rather than through ambient canonical names.

The provisioner-side credential resolution is the part to design carefully and the reason this is a
slice of its own rather than a field addition.

Acceptance criteria

• An ownership record carrying a non-canonical AWSOptions mapping reaches the provisioner with
  that mapping intact.
• A test proves the resolved credentials come from the record's mapping and not from the ambient
  canonical AWS_* variables — the two must be set to different values so the assertion can
  distinguish them.
• Existing construction sites that supply no mapping keep their current behaviour, pinned by a
  control test.

Size: medium — one additive type change, one population site, provisioner credential resolution,
plus tests.

Part of #6203. Raised on #6385.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• EKS ownership binding discards the recorded AWS credential mapping #6400

🔗 Related PRs

#5826 - feat(operator): implement Connector for EKS (AWS SDK-built kubeconfig) [merged]
#5913 - feat(cluster): report real EKS status in cluster info [merged]
#5998 - fix(eks): report control-plane endpoint in EKS provider status [merged]
#6089 - fix(eks): honor custom AWS credential mappings [merged]
#6194 - ci(eks): enforce smoke-test role boundaries [merged]
#6267 - feat(eks): graduate in-place node scaling [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!