[test] Add stabilization waits to Add Cluster webview

[vrubezhny]

Summary

Fix intermittent public UI test failures for Material-UI-based webviews (Add Cluster, Create Component, Serverless Function) by replacing tight-loop DOM polling with sparse checks.

Background

These failures were first noticed after the survey 3.0.0 bump, but none of the affected webviews (Add Cluster, Create Component, Serverless Function) actually use the survey package - only the feedback webview does. The real issue is generic: async Material-UI rendering combined with how the tests were polling for elements.

Root cause

A tight driver.wait() loop re-runs an XPath query on the webview's single JS thread every ~200ms. This can compete with the page's own async rendering work for that same thread instead of just waiting for it - potentially delaying the very rendering the loop is waiting for. One test file (newComponentWebViewEditor.ts) went further and re-entered the webview frame (switchToFrame/switchBack) on every poll iteration, which is even more expensive per cycle.

Separately, CI runner contention (three OS runners plus other PRs running in parallel) appears to compound the slowness - the same test code was observed to pass reliably when re-run in isolation.

Changes

• Added a shared findElementSparse() helper to the WebViewForm base class: tries immediately first (so already-rendered pages pay no extra latency), then falls back to sleeping upfront and checking infrequently instead of tight-looping.
• Replaced tight-loop polling in AddClusterWebView, ServerlessFunctionWebViewEditor, and CreateComponentWebView/GitProjectPage/LocalCodeBasePage with this helper.
• Refactored createComponentFromTemplate/FromGit/FromLocalCodebase to enter the webview frame once instead of re-entering it on every poll iteration.
• Widened the Add Cluster button-finding timeout to 35s, and fixed two Add Cluster tests that had no explicit mocha timeout at all (silently falling back to the 7s global default - too short for a page that can take longer to render under CI load).
• Added descriptive chai expect() assertions to pinpoint exact failures instead of generic timeouts.

addServiceBinding.ts and createServiceWebView.ts use the same tight-loop pattern but haven't shown failures - left as-is for now since they're subject to unrelated upcoming changes.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 50.61%. Comparing base (da60441) to head (4217d84).
⚠️ Report is 1954 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff             @@
##             main    #6039       +/-   ##
===========================================
+ Coverage   32.37%   50.61%   +18.23%     
===========================================
  Files          85      114       +29     
  Lines        6505    10389     +3884     
  Branches     1349     2334      +985     
===========================================
+ Hits         2106     5258     +3152     
- Misses       4399     5128      +729     
- Partials        0        3        +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.