Cover mid-edit renames from Markdown in the "Preview" tab

What does this MR do and why?

Follow-up to Follow mid-edit renames to Markdown in the "Pre... (!250889 - merged) and Follow mid-edit renames in the preview renderer (!251790 - merged). Test coverage only, no implementation changes. Closes "Preview" tab does not follow mid-edit file ren... (#616115 - closed).

Adds feature specs verifying that the "Preview" tab follows a mid-edit rename away from Markdown.

Why this had to wait for both MRs

Each quadrant of the rename matrix leans on a different fix:

from \ to	Markdown	non-Markdown
Markdown	Unify the definitions of "Markdown" behind edit... (!253025 - merged)	both Follow mid-edit renames to Markdown in the "Pre... (!250889 - merged) and Follow mid-edit renames in the preview renderer (!251790 - merged) — covered here!
non-Markdown	Follow mid-edit renames to Markdown in the "Pre... (!250889 - merged)	Follow mid-edit renames in the preview renderer (!251790 - merged)

A rename away from Markdown needs the tab to leave the live preview (Follow mid-edit renames to Markdown in the "Pre... (!250889 - merged)) and the renderer to follow the edited file name (Follow mid-edit renames in the preview renderer (!251790 - merged)). Either fix alone isn't enough, so these specs could only land once both had merged.

Screen recordings

Before both MRs	After (current GitLab.com)

How to set up and validate locally

1. In a repository, create a file named foo.md with some Markdown content and commit it
2. Open foo.md in the single file editor
3. Rename it to foo.org and write some Org-mode content (e.g. * Title)
4. Click the "Preview" tab
5. Verify that the content is rendered as an Org-mode heading, not as an Markdown bullet list

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.