[EKS] [request]: Surface internal etcd/control-plane replacement status to avoid sequential upgrade blocking

### Community Note

* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment

**Tell us about your request**
- Expose the internal etcd and control-plane node replacement / maintenance status in EKS so users can understand when internal upgrades are still in progress, preventing unexpected “update in progress” errors during sequential version upgrades.

**Which service(s) is this request for?**
- Amazon EKS

**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
- We want to perform sequential control plane version upgrades (e.g. 1.30 → 1.31, then 1.31 → 1.32) immediately. Although the cluster version reports ACTIVE and no visible update is in progress, the second upgrade fails with: `Cannot VersionUpdate because cluster currently has an update in progress`.
- AWS support confirmed that after the version upgrade, internal etcd or control-plane instance replacement is underway, but this internal process is not surfaced to users via console, API, or Upgrade Insights. Users cannot know when it completes, leading to retries, delays, automation failures, and confusion.

**Are you currently working around this issue?**
We add arbitrary delays between upgrade steps, detecting success manually, retrying until the update succeeds. This incurs time loss and complexity in automation.

**Additional context**
- Observed sequence:
1. Upgrade from 1.30 → 1.31 proceeds and version changes to 1.31.
2. Internal etcd/control-plane replacement begins automatically. (This is not visible to us)
3. Immediately sending upgrade request to 1.32 fails with “update in progress.”
4. After internal replacement completes, 1.32 upgrade succeeds.
- Improvement suggestions:
* Provide an API or console field showing internal etcd/control-plane replacement in progress.
* Include this state in EKS Upgrade Insights or cluster status.
* Adjust error message to indicate “blocked by internal etcd/control-plane replacement” instead of ambiguous “update in progress.”

**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)

Start by reviewing the Amazon EKS API, console, and Upgrade Insights entry points referenced in the request. Confirm how the cluster currently reports ACTIVE during internal etcd or control-plane replacement, and compare the requested status and error-message behavior with the documented upgrade flow. Done means users can identify when replacement is still blocking a sequential upgrade.

Written by the indexing model from the issue text.