test: stabilize release WebKit readiness checks

[astandrik]

Follow-up from #4389. This tracks historical release-suite failures separately from acceptance of the GitHub release runner.

Evidence

Release UI/test revision: 85e1e1d44e7df6b0f69b4a81e92d2336fb809941 (15.6.0-hotfix.1), backend local-ydb:26.2.1.14, frontend npm-start, Playwright 1.58.0, retries disabled.

• First run: 667 passed, 2 failed, 3 skipped. WebKit failed Storage usage renders multiple media sections.
• Second run: 665 passed, 4 failed, 3 skipped. WebKit failed on: shows Bridge piles section with data, Storage usage shows zero data size when table stats report 0 bytes, and Storage usage shows response error when storage groups request fails. The other failure is the separately tracked hotkeys scenario.
• All eight shards ran. Both runs have complete merged reports; these are individual assertion failures, not missing reports or unstarted shards. Failure screenshots, videos, contexts and traces are in the release-e2e-report artifact.

The second run's traces show the Bridge locator timing out after 3 seconds and Storage locators after 5 seconds. The immediately following snapshots contain the expected Bridge piles, the 0 GB storage view and the mocked HTTP 500 error respectively. The affected scenarios pass in the other run. This confirms timing-sensitive test failures; it does not prove the precise asynchronous cause or a current product regression.

Relevant pinned sources:

• ClusterPage.ts, 3-second wait
• Bridge test
• Storage usage tests

Scope and acceptance

• Identify the response/render readiness boundary in the retained traces and reproduce with retries disabled. Synchronize on the relevant response and rendered state without masking failures with retries, skips or global timeout increases.
• Reuse existing work where applicable: chore: flapping test #4003 / chore: stabilize storage usage e2e #4007 cover the historical single-media Storage wait, not proof that all scenarios above are fixed. Current main has additional waits; validate compatibility before porting them to the release test revision.
• Produce a minimal test revision compatible with UI 15.6.0-hotfix.1, or demonstrate that an existing compatible revision resolves these cases. Keep frontend/backend identity explicit. ci: allow a separate test revision for release e2e #4390 provides an optional separate test SHA; it does not make arbitrary main tests compatible with this UI.
• Verify affected cases in Chromium and WebKit with retries disabled, then run the complete release suite and retain both source SHAs and reports. Do not modify the published release tag or change the default revision selection to hide failures.

A fresh browser reproduction and a complete root-cause diagnosis have not yet been performed; this issue is based on two existing CI runs and their retained traces.