tests: master's slow leg - the dashboard now names itself twice

[delchev]

The break

MultitenancyHarmoniaIT has failed on every master run since #7413, in both the H2 and the PostgreSQL slow legs — first seen in run 35192425278, still failing in the latest completed run:

Found [2] elements by [By.tagName: span] and conditions [[exist, match text "\QDashboard\E"]] but expected at most one.
  at MultitenancyHarmoniaITTestProject.verifyHomePageAccessibleByTenant(...:105)

The second element is intended. #7413 made breadcrumbTrail return a Dashboard crumb where it used to return an empty trail, so the label is on the home page twice: the sidebar entry that opens the page, and the breadcrumb of the page it opened. assertElementExistsByTypeAndContainsText fails on more than one match, so the test broke on a correct product change.

The change

The assertion checks that the tenant can reach its home page, which more than one match does not disprove — so the test asks for at least one match. assertAnyElementExistsByTypeAndContainsText is the tolerant twin of the existing assertion: the same frame-walking search with the "expected at most one" guard lifted, failing with a screenshot when nothing matches. The strict method is untouched and stays the default for anything that must be unique.

Verified

• MultitenancyHarmoniaIT green locally on H2: Tests run: 3, Failures: 0, Errors: 0 (the two tests that fail on master among them).
• mvn -T 1C formatter:validate green with the formatter cache wiped first.
• Not run locally: the PostgreSQL leg (CI covers it; the failure is DB-independent).

Not this break

• BPMStarterTemplateIT timed out in the ui legs of run 35223726746 but passed at the same SHA in 35192425278 — a flake, not addressed here.
• The PostgreSQL slow leg also hit a Liquibase Could not acquire change log lock cascade in 35192425278 (which is what pushed that job past its 1h30m limit); it did not recur in the next run at the same SHA.

🤖 Generated with Claude Code