create/update addon --wait aborts on a transient DEGRADED instead of waiting for recovery #8895

What happened?

eksctl create addon --wait aborts if the addon reports DEGRADED at any point, instead of
continuing to wait for it to recover. On a freshly created addon this is a race, and it fails
intermittently.

Seen in the addons integration suite, spec should support advanced addon configuration
(integration/tests/addons/addons_test.go:333). The spec deletes coredns, then recreates it with
{"replicaCount":1} and --wait. 25 seconds later:

Error: addon status transitioned to "DEGRADED"

Why it happens

waitForAddonToBeActive (pkg/actions/addon/addon.go) delegates to the SDK's
eks.NewAddonActiveWaiter, whose acceptor treats DEGRADED as terminal:

expectedValue := "DEGRADED"
if pathValue == expectedValue {
    return false, fmt.Errorf("waiter state transitioned to Failure")
}

The waiter's first poll is at ~10s. A freshly created addon — recreated immediately after a delete,
with a single replica — can legitimately report DEGRADED for a few seconds while that replica is
scheduled and passes readiness. If a poll lands in that window, eksctl gives up on an addon that
would have become ACTIVE moments later.

eksctl already knows this happens. Immediately above that call:

// Don't wait for coredns, aws-ebs-csi-driver or aws-efs-csi-driver if there are no nodegroups.
// They will be in degraded state until nodegroups are added.

That guard only covers the no-nodegroup case. When the cluster does have nodes, the wait runs and
the race is live.

Why it's worth fixing

This is user-facing, not just a test problem: anyone running eksctl create addon --wait (or
update addon --wait) can have the command fail on an addon that is simply still starting. The
failure is also misleading — it reports a terminal-sounding error for a transient state.

Suggested fix

Treat DEGRADED as non-terminal during create/update and keep waiting until either ACTIVE or the
timeout, rather than inheriting the SDK acceptor's verdict. Options:

1. Replace the generated waiter with a poll loop that only treats CREATE_FAILED / UPDATE_FAILED as
   terminal and tolerates DEGRADED until the timeout expires. pkg/eks/waiter already provides the
   scaffold for a hand-written waiter with a custom Retryable hook.
2. Keep the SDK waiter but, on a DEGRADED verdict, re-enter the wait with the remaining budget — so
   a sustained DEGRADED still fails at timeout while a transient one recovers.
3. Extend the existing coredns/ebs-csi/efs-csi special case to allow a grace period after creation.

Option 1 is the cleanest; the timeout remains the real bound, which is what the user asked for by
passing --wait.

Versions

Reproduced against main (0.231.0-dev), integration suite `addons`, us-west-2.
coredns v1.13.2-eksbuild.47, Kubernetes 1.34