[release/v25.2.x] acceptance: extend cluster-ready timeout to 10m to reduce flakiness

[david-yu]

Summary

Several acceptance scenarios on release/v25.2.x fail at exactly the
5-minute cluster-ready boundary while the cluster eventually does come
up. Runners on this branch routinely take 5–7 minutes to bring a
Redpanda cluster to Ready under load (image pull, PVC binding,
operator reconcile under k3d contention). Without this change a slow
start is indistinguishable from a stuck cluster: tests time out
mid-startup with Condition never satisfied.

This PR centralizes the per-step Eventually budget into two constants
in acceptance/steps/cluster.go:

const clusterReadyTimeout = 10 * time.Minute  // was 5*time.Minute literal
const clusterReadyPoll    = 5  * time.Second

and replaces the 5*time.Minute, 5*time.Second pairs across the
acceptance/steps/ files that wait on cluster readiness:

File	Sites
cluster.go	6
k8s.go	3
regression.go	2
rpk.go	1
service.go	1

Why v25.2.x only

Same diff would benefit other release branches in principle, but
release/v25.3.x and release/v26.1.x acceptance runs pass on the
same k8s-m6id12xlarge agent class within the current 5-minute
budget (see #1538 / #1539 — same rolling-restart backport diff, both
green). The flakiness is specific to v25.2.x: slower operator
startup, slower image pull, and shared k3d state that's drifted with
time-in-maintenance.

Centralizing the constant means we can re-tune in one place if we want
to apply this to other branches later.

Failure shape this targets

From recent runs of #1540 against this branch:

TestAcceptanceSuite/Skipping_incremental_scale_downs         (307.20s)  FAIL
TestAcceptanceSuite/Manage_ShadowLink                        (356.35s)  FAIL
TestAcceptanceSuite/Operator_upgrade_from_25.1.3             (342.87s)  FAIL
TestAcceptanceSuite/Migrate_from_a_Helm_chart_release_to...  (320.74s)  FAIL

All clustered at the 300–350s mark — i.e. the 5-minute Eventually
budget ran out while Checking cluster resource conditions contains "Ready"? false was still being repeated. With a 10-minute ceiling we
absorb the slow-but-correct path.

Zero overlap in which test fails per run, and the failures are in
unrelated areas (schema CRDs, shadow links, scale-up, upgrade-matrix)
— this is timing pressure on the shared k3d cluster, not a code
regression. Bumping the ceiling lets the slow-but-correct path complete
instead of being indistinguishable from a stuck cluster.

Scope this does NOT cover

• Per-scenario k3d cluster isolation. Some runs (e.g. [backport release/v25.2.x] operator: defer rolling restart while a recently replaced pod is still coming up #1540 run 3)
  show 7 consecutive tests timing out simultaneously, which looks like
  a single k3d cluster died and contaminated the rest of the suite.
  Real fix is to isolate each scenario in its own k3d instance, at the
  cost of ~25 min per acceptance run. Separate PR if we want it.
• Pinning of published chart artifacts. The upgrade-matrix tests
  reference --version v25.1.3 etc. which are already version-pinned,
  but pull container images that can drift at the registry. Out of
  scope; a separate PR would convert chart references to digests.

Test plan

• go build ./acceptance/... — clean
• go vet ./acceptance/... — clean
• Acceptance suite on release/v25.2.x — observe whether the
  cluster-ready-timeout failures disappear; run multiple times to
  confirm independence of randomized seed.

🤖 Generated with Claude Code

[RafalKorepta]

Maybe it will be better to merge #1542 into your PR as you fix flaky test, but buildkite configuration is broken and prevents from merging