core: compare theme variants as an unordered set in assertTheme

[jcgueriaud1]

Problem

assertTheme(...) matched the whole theme attribute as a raw string. Flow serializes every applied theme variant into that single attribute in an order it controls — not the order the variants were added — so the match is brittle:

Locator expected to have attribute 'theme'
Expected: small primary
Received: primary small

button.addThemeVariants(LUMO_PRIMARY, LUMO_SMALL) renders as small primary on Vaadin 25.3.0-beta1 and as primary small on 25.3.0-rc1, breaking ButtonViewIT.testHasThemeVariant. This PR is what unblocks the rc1 bump in #184.

Fix

assertTheme compares the variants as an unordered set: it builds a pattern with one anchored lookahead per expected variant plus a token count, so

• assertTheme("small primary") and assertTheme("primary small") both pass,
• an extra unexpected variant still fails (the count clause catches it),
• Playwright's auto-retry and timeout behaviour are unchanged — it is still hasAttribute(name, Pattern).

The hand-rolled metacharacter escaping (Playwright compiles patterns into a JS RegExp, which does not understand Pattern.quote's \Q...\E) is factored into a shared escape() helper used by both the set pattern and the existing single-variant pattern. assertHasThemeVariant / assertHasNoThemeVariant are unchanged.

Also updated: the "Theme Variant Order" pitfall in AGENTS.md, the BadgeElement.md spec wording, the regenerated api-reference.md, and ButtonViewIT, which now asserts both orderings.

Testing

mvn verify on the current beta1: 717 tests, 0 failures. On rc1 (i.e. with #184 applied): 717 tests, 0 failures.

🤖 Generated with Claude Code