[Bug]: iOS file-link chips replace descriptive link labels again (regression of #10787) #28509

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/mobile

Steps to reproduce

1. On iOS, open a Markdown file from a project in the file preview, or view an assistant message in a thread.

2. The Markdown contains a file link whose label is descriptive text rather than the file name. For example, with an existing docs/guide.md:

   See [the setup steps](docs/guide.md) before running the server.

3. Read the rendered sentence.

Expected behavior

The link shows its authored text, the setup steps, and still opens docs/guide.md. This is the behavior #10787 asked for and #15509 implemented.

Actual behavior

The authored text is replaced by a file chip showing the file name, so the sentence reads roughly:

See guide.md before running the server.

This looks like a regression of #10787 on iOS after the switch to the Enriched Markdown renderer. #15509 fixed the native t3-markdown-text module and ThreadFeed, but the current iOS path does not go through that code:

• SelectableMarkdownText renders MobileEnrichedMarkdownText on iOS (SelectableMarkdownText.tsx#L27). The Markdown file preview uses it too (FileMarkdownPreview.tsx#L238).
• MobileEnrichedMarkdownText gets link labels from useEnrichedLinkVariants (EnrichedMarkdownText.tsx#L203).
• In presentation(), any href that resolveMarkdownLinkPresentation treats as a file returns label: link.label, which is the basename plus optional line. The authored link text is never consulted (useEnrichedLinkVariants.ts#L76-L81). That label then becomes the pill text (useEnrichedLinkVariants.ts#L158).

Impact

Minor bug or occasional failure

Version or commit

Observed in the iOS app 2.2.0. Source checked at 5732bbee397f0a2b0e61d0c2e432f01dca6df3dc (current main).

Environment

iOS app 2.2.0, Markdown file preview and thread messages. Desktop server 0.1.5 on macOS. Independent of provider.

Workaround

Keep the descriptive text outside the link and use a file-name-only label, as noted in #10787: the setup steps, see [guide.md](docs/guide.md).

Suggested fix

Apply the #15509 rule in the Enriched path as well: keep the chip label when the authored text is already the basename, a path, or file:line; otherwise keep the authored text and attach the destination (icon, line) to it. This probably needs the authored link text passed through to useEnrichedLinkVariants, since it currently only receives URLs.