[BUG] Searching within a rendered markdown file switches the viewer to code mode, and returning to rendered view resets scroll to the top

What happens

In the desktop app's file viewer, using search inside a markdown file being shown in rendered view switches the display to code mode. Code mode uses a smaller, narrower font that is markedly harder to read for long prose documents.

Switching back to the rendered view then returns the document to the top, discarding the position the search had just located.

Why it matters

These two behaviours combine into a dead end. Markdown links open a file at the top with no way to target a position, so search is the only means of reaching a specific place in a long document. But searching costs the readable rendering, and restoring the readable rendering costs the position — so the user ends up back at the top of the file, which is where they started.

For long structured documents that are read rather than skimmed — notes, plans, work queues — the rendered view is not a preference. Headings, emphasis and list structure are how the document is navigated at all.

Steps to reproduce

1. Open a long markdown file in the desktop app's file viewer, in rendered view.
2. Search for a string that occurs well down the document. The view switches to code mode and moves to the match.
3. Switch back to rendered view.

Expected: the rendered view is restored at or near the match; ideally search works without leaving rendered view at all.
Actual: the rendered view is restored at the top of the document, and the match position is lost.

Related

Possibly the same area as #83475 (a :N line suffix silently kills a markdown link, while working on code files) and #83476 (markdown files are not editable in the viewer as code files are). All three make rendered markdown a second-class citizen relative to code files in the same viewer.

Environment

Desktop app on Windows 11, version 2.1.219–2.1.220.