Fix grapheme-vs-UTF-16 range bug in RichContentFormatter

[jkmassel]

What this fixes

RichContentFormatter sized the NSRange it hands to NSRegularExpression from content.count — Swift's grapheme-cluster count — but NSRegularExpression matches over UTF-16. When content contains multi-code-unit characters (emoji, flags, ZWJ/combining sequences) the grapheme count is shorter than the UTF-16 length, so the search range stops short of the end and any forbidden tag, inline style, or gallery-image src near the end is silently left untouched — unsanitized markup then reaches the rendered Reader post or comment.

A single family emoji 👨‍👩‍👧‍👦 is one grapheme but eleven UTF-16 units, so a <script> placed right after it begins ten units past where the grapheme-count range ends: the whole tag falls outside the search and survives.

ASCII content is unaffected — there the grapheme count equals the UTF-16 length, which is why this went unnoticed.

Changes

• Size every search range in UTF-16. The whole-string ranges across removeForbiddenTags, normalizeParagraphs, filterNewLines, and removeInlineStyles now come from String.utf16.count, and removeTrailingBreakTags ranges over UTF-16 too.
• removeTrailingBreakTags no longer mixes offset spaces. It fed a UTF-16 match.range.location to String.index(_:offsetBy:), which counts graphemes — already wrong for multibyte content, and a hard crash (String index is out of bounds) once the range widened. It now converts the match with Range(match.range, in: content).
• resizeGalleryImageURL had the same bug. This display-pipeline step rewrites a gallery image's src to a Photon/resized URL; it sized the replacement range from imgElementStr.count, so a src sitting past a multibyte cluster was never rewritten and the full-size original loaded instead. It runs on rendered comments (CommentService → formatContentString). Now sized in UTF-16.
• Harden parseValueForAttribute against malformed markup. A separate crash in the same file: it searched for an attribute's closing quote and passed the result to substring(with:) unguarded, so an opening quote with no close (NSNotFound) underflowed the range length to an out-of-bounds NSRange and trapped. It now returns "" when the closing quote is missing, matching the attribute-not-found default.
• Migrate the tests to Swift Testing. The RichContentFormatter test files move from XCTest to @Test/#expect, matching the rest of the WordPressSharedTests target — same inputs, same assertions.

formatGutenbergGallery and formatVideoTags already ranged over NSString.length and are untouched.

The whole-string ranges are sized with content.utf16.count inline, matching the convention #25341 established across the rest of the codebase.

Split into three commits for review: the fix (with regression tests), the Swift Testing migration, and the parseValueForAttribute hardening.

Tests

One isolated test per fix site — each forbidden-tag regex, each normalizeParagraphs sub-site, the three filterNewLines paths, the inline-style site, and the trailing-break range plus its index-offset cut — using a spread of multi-code-unit clusters (astral emoji, a ZWJ family, a flag, a keycap, a skin-tone modifier, and an NFD combining mark), positioned so the target token lands in the tail the grapheme-count range dropped. Each input holds one tag type, so reverting any single site breaks exactly one test; the exact-output assertions also confirm the cluster survives byte-for-byte. Two further tests pin the exact off-by-one boundary and confirm the corrected range strips the intended tag rather than everything.

parseValueForAttribute gets three direct tests, including a malformed element (opening quote, no close) that crashes the pre-fix code with an out-of-bounds NSRange and returns "" after the fix.

resizeGalleryImageURL's regression lives in RichContentFormatterUITests — it needs UIKit, so it runs in the iOS WordPressUnitTests plan, not the macOS swift test set.

Stacking

Stacked on #25832 (base jkmassel/wordpressdata-swift-test), which removes WordPressData's WordPressUI/WordPressSharedUI dependencies and, as part of that, splits RichContentFormatter's platform-independent core into cross-platform WordPressShared — which is what lets this fix and its regression tests run on macOS under swift test. The bug is pre-existing; it's also on trunk, in the pre-split WordPressSharedUI copy. This PR retargets to trunk once #25832 merges.

Test plan

• swift test --filter RichContentFormatterTests (macOS host) → 26/26. 15 of the 16 multibyte tests fail on the pre-fix source (the 16th is a no-tags idempotence guard that passes either way); the parseValueForAttribute missing-closing-quote test traps the pre-fix code with an out-of-bounds NSRange.
• Run the iOS WordPressUnitTests plan (or rely on CI): RichContentFormatterUITests.testResizeGalleryImageURLReplacesSrcPastMultibyteCluster — a gallery <img data-orig-file=… alt="😀😀😀😀😀" src=…/> comes back with its src swapped to a *.wp.com URL (0 replacements on the pre-fix source).

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress by scanning the QR code below to install the corresponding build.

	App Name	WordPress
	Configuration	Release-Alpha
	Build Number	34358
	Version	PR #25833
	Bundle ID	org.wordpress.alpha
	Commit	1235488
	Installation URL	396c4kc1u198g

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack by scanning the QR code below to install the corresponding build.

	App Name	Jetpack
	Configuration	Release-Alpha
	Build Number	34358
	Version	PR #25833
	Bundle ID	com.jetpack.alpha
	Commit	1235488
	Installation URL	22bhrg98q33kg

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[wpmobilebot]

🤖 Build Failure Analysis

This build has failures. Claude has analyzed them - check the build annotations for details.