fix(flow): fold invisible characters before comparing UI text

[hubgan]

Stacked on #719.

The problem

UI text is not the text an author types. A currency label renders with a non-breaking space; a layout wraps a user-supplied name in bidi isolates; a soft hyphen or ZWSP survives a copy-paste. All of them survived toLowerCase(), so a check failed against two strings that are character-for-character identical on screen and in the failure message:

element matched but its text was "Amount, PLN 42.00" (wanted to equal "Amount, PLN 42.00")
success: false, elapsed: 15001

Two sessions paid a full 15-second timeout per attempt to that, plus extra probe cycles. In CI it is an unexplainable red build.

What changes

Every literal comparison (equalsCI, includesCI, identifierMatches) folds both sides first: NFC, invisible formatting stripped, space-like codepoints reduced to a plain space, whitespace runs collapsed, trimmed, lowercased. matches (regex) is deliberately exempt — a pattern carries its own precision.

The invariant, and what it rules out

Folding only ever removes distinctions the eye cannot see. Two consequences follow, and both are load-bearing:

NFC, not NFKC. Compatibility normalization folds away differences that read perfectly well — mathematical alphanumerics, ligatures, fullwidth forms. Under NFKC a blackletter display name compared equal to its plain-ASCII spelling, so a check could not tell an impersonating account from the real one. A silently-wrong green is worse than a flake.

ZWJ and variation selectors are not stripped. They are invisible alone but load-bearing in sequence: the transgender flag is U+1F3F3 VS16 ZWJ U+26A7 VS16 — one glyph. Stripping them folded it onto two separate glyphs, so a text check passed against a visibly different display name, and a broken sequence — a real rendering regression — became invisible to every check. ZWNJ is a spelling difference in Arabic, Persian and Indic scripts.

Bidi wrappers are folded, and are not a theoretical case: a census of four Bluesky web screens found 367 U+202A/U+202C pairs and not a single NBSP. Omitting them would have left the most common real instance of this bug unfixed.

Two failure notes for what folding deliberately does not fix

• Codepoint diff. When two strings differ only in invisible characters, the note prints both as codepoint sequences instead of quoting identical-looking text twice. It keys on Unicode category Cf, strictly wider than the fold's explicit classes, so it is the safety net for invisible characters not on that list.
• Typographic variant. An author types ... for a label the app renders with … and gets "no element matched", which points at nothing. The failure now names the text the screen actually shows and says why the two are not equated.

Unrelated hole closed in passing

A needle that folds away to nothing is now no constraint rather than a weak one. "".includes() is true of every string, so { role: " " } matched every element on the screen and the check could never fail.