Fix Markdown preview crash on UTF-8 files with >2MB size and <1.5M characters

[Copilot]

NavigateToString throws ArgumentException when previewing Markdown files containing many multi-byte UTF-8 characters (e.g., CJK) — file size exceeds 2MB but character count stays under 1.5M, bypassing the guard.

Summary of the Pull Request

The size guard in MarkdownPreviewHandlerControl used markdownHTML.Length (character count / UTF-16 code units), but WebView2's NavigateToString limit is measured in bytes. A string with 700K CJK characters has only 700K .Length units but ~2.1MB of UTF-8 bytes — enough to crash the API while passing the old check.

Changes:

• MarkdownPreviewHandlerControl.cs: Replace character-count guard with UTF-8 byte count:

  // Before
  if (markdownHTML.Length > 1_500_000)
  
  // After
  if (System.Text.Encoding.UTF8.GetByteCount(markdownHTML) > 1_500_000)

  When the byte threshold is exceeded, content is written to a temp file and loaded via _browser.Source instead of NavigateToString — existing fallback path, now correctly triggered.

• MarkdownPreviewHandlerTest.cs: Added 3 regression tests to prevent this class of bug from recurring:

  1. Multi-byte UTF-8 content (CJK, <1.5M chars but >2MB bytes) → temp-file navigation path
  2. Small ASCII content within both thresholds → NavigateToString path
  3. Large ASCII content exceeding 1.5M chars → temp-file navigation path

PR Checklist

• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

The existing fallback (write HTML to a temp file, navigate via _browser.Source) was already correct and handles arbitrarily large content safely. The only bug was in the guard condition that decides when to use it — it measured the wrong unit (characters vs. bytes). Single-byte ASCII content is unaffected; only multi-byte Unicode content was under-counted.

The tests use reflection to read the private _localFileURI field. Since this field is set synchronously before Controls.Add(_browser), the check is race-free: once the wait loop exits with Controls.Count > 0, _localFileURI is guaranteed to have its final value.

Validation Steps Performed

• Verified the fix by reasoning through the byte math: a file with 700K CJK characters → Length = 700K (passes old check) → UTF-8 bytes ≈ 2.1MB (fails new check → uses temp file path, no crash).
• Added 3 targeted unit tests in UnitTests-MarkdownPreviewHandler covering the multi-byte threshold boundary; all 14 tests in the suite pass (14/14).

[Copilot]

Pull request overview

This PR updates Markdown preview sizing logic so WebView2 avoids NavigateToString for HTML whose UTF-8 byte size exceeds the safe threshold, preventing crashes with large multi-byte Unicode Markdown content.

Changes:

• Replaces string.Length threshold checking with Encoding.UTF8.GetByteCount.
• Updates comments to clarify the WebView2 limit is byte-size sensitive.

[MuyuanMS]

Added the requested coverage in MarkdownPreviewHandlerTest.cs:

• multi-byte UTF-8 content under 1.5M chars but over 2MB -> temp-file navigation
• content under both thresholds -> NavigateToString
• ASCII content over 1.5M chars -> temp-file navigation

The tests verify the navigation path by checking whether _localFileURI is populated and, for temp-file cases, that the WebView source points to the generated file. I also rebuilt the handler/test projects with MSBuild and ran PreviewPaneUnitTests via vstest.console.exe (14/14 passing).

[MuyuanMS]

@copilot please re-review the latest changes.