feat: mention and citation links with custom event handler and styling support (display only)

[xindixu]

What/Why?

Add mention and citation links to the <EnrichedMarkdownText /> component only. Supports custom event handler and styling.

Testing

Manually performed these tests

• Mention and citation with custom styling background, border, color, and padding
• Copy as text and copy as markdown
• Styling looks correct when they are rendered inside: paragraph, block quotes, tables, lists
• Clicking/pressing the mention and citation links work as expected

Screenshots

iOS	Android	Web

PR Checklist

• Code compiles and runs on iOS
• Code compiles and runs on Android
• Updated documentation/README if applicable
• Ran example app to verify changes

[hryhoriiK97]

@xindixu thanks a lot for the PR! Really appreciate it.

A few pieces of feedback before we move forward:

The PR is too large to land as-is

~3k lines across ~70 files, bundling at least four independent concerns:

• BlockquoteSpan rework + new SPAN_FLAGS_CONTAINER_BACKGROUND priority flag — useful on its own, affects every blockquote consumer.
• Build/env fixes (podspec HEADER_SEARCH_PATHS, CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES, Gemfile nkf).
• Citations.
• Mentions.

Mentions

We have a parser-level approach in flight: hryhoriiK97/md4c#1 adds a real MD_SPAN_MENTION extension to the md4c fork we already use. Syntax: @[display](target) / #[display](target). The indicator and free-form target are surfaced via MD_SPAN_MENTION_DETAIL, and the application interprets the target.

Why do we prefer that over URL-scheme encoding on Link:

• First-class AST node — fits the existing "md4c → AST → per-platform renderer" pipeline (same shape as spoiler, math, underline). The current PR forces parallel if (url.startsWith("mention://")) branches into LinkRenderer on iOS / Android / web, plus MarkdownExtractor, LinkTapUtils, PasteboardUtils, SelectionActionMode, and the table tap path. That branching grows linearly with each new "kind of inline."
• Editor support becomes possible. A real AST node lets ENRMInputParser / InputParser.kt recognise mentions atomically in EnrichedMarkdownInput (select-as-one, delete-as-one, @-typing autocomplete). URL-scheme encoding is display-only on EnrichedMarkdownText with no clean path to editor support.
• No collisions — any existing [text](mention://...) a consumer authored before enabling the feature would silently turn into a mention. With distinct syntax, regular link behaviour is unchanged for everyone who doesn't enable the flag.
• Cleaner event payload — { indicator, target, displayText } instead of consumers re-parsing mention://uuid?type=user.

Citations

Worth discussing separately in an issue — they're link-shaped (clickable URL reference), so the design choice (separate md4c extension vs. styled-link convention vs. not shipping) is independent from mentions.

Suggested next steps

• Mentions: land via the md4c PR + AST integration once it merges. Happy to share the integration plan then.
• Citations — let's discuss in an issue to settle on the design before writing any code.
• BlockquoteSpan + SPAN_FLAGS_CONTAINER_BACKGROUND — could land as its own small PR, unblocks any future inline-chip work. Could you please open a separate PR containing only this change? 🙏
• Podspec / Gemfile fixes — could you share the exact build errors each one resolves, along with the RN/Xcode/Ruby versions where they reproduce? If you can, please open a separate issue with a reproduction. We don't see those problems on our current setup.

Thanks for your patience and understanding! We want to build a generic solution that works across various use cases and remains easier to maintain and scale - it just takes a bit more time and effort. 🙂

[xindixu]

@hryhoriiK97 Thank you for the advice! I'll work on these next week!

[xindixu]

@hryhoriiK97 I've pulled out blockquote related fixes here: #253