Feature request: configurable CJK font fallback for mixed-script Markdown #1001

Is your feature request related to a problem? Please describe.

Applications displaying mixed Latin and CJK Markdown may want a specific CJK typeface while preserving their existing Latin font and code font. For example, prose should retain its Latin face, code should retain its monospace Latin face, and supported Chinese characters in both should use an application-provided CJK face.

markdownStyle.*.fontFamily selects a font for a whole element. It does not expose a fallback chain or character-range font selection, so an application cannot express this mixed-font policy through the current API. System fallback provides readable text but cannot select the application's desired CJK face.

Describe the solution you'd like

A generic, optional font-fallback or character-range font configuration for native Markdown rendering, with the API shape open to discussion.

• Allow applications to supply registered font families and, if necessary, supported Unicode ranges or another coverage mechanism.
• Apply the selected font only to characters it supports; retain the existing face for Latin and leave unsupported glyphs, including emoji, to normal fallback.
• Work across prose, headings, inline code, fenced code blocks, and table cells.
• Preserve the surrounding size, weight, and italic treatment where the selected font supports them.
• Use the same resolution for measurement and rendering, including streaming updates, and preserve composed characters and variation selectors.
• Handle missing/unavailable fallback fonts gracefully.

The library should not bundle a particular CJK font or assume application-specific asset names, resource bundles, or coverage files. Android and iOS are the immediate use case; platform differences should be documented.

Describe alternatives you've considered

Using a CJK font as the whole element's primary family does not preserve the selected Latin/code face. System fallback cannot select a specific custom CJK family. Building combined font assets in the application may work for a fixed font set, but requires separate asset preparation and maintenance for each family/weight combination. Splitting text into nested React Text runs is not exposed by the native Markdown renderer.

Additional context

We currently carry a downstream patch against react-native-enriched-markdown 1.0.2 that applies a custom CJK font by glyph coverage on Android and iOS. Its hardcoded font and asset identifiers are application-specific; we would not propose those upstream. This request is to discuss a reusable extension point, with mixed-script, emoji, table/code, and measurement coverage before implementation.