Suggest mentioned users in quick actions

What does this MR do and why?

When one or more users are mentioned in a rich text editor or markdown description or comment, then suggest those mentioned users for any slash commands (quick actions) that take user mentions as arguments.

Screenshots or screen recordings

	Before	After
Rich text editor
Markdown

How to set up and validate locally

1. In your GDK, open a Merge Request or Issue that has at least 3 project members, and note 2-3 usernames (pick ones that do NOT sort first alphabetically so reordering is obvious).
2. In the comment box, confirm the Markdown (Source) editing mode is active.
3. Validate the basic case in the Markdown editor:
   1. Open a fresh comment, type /request_review @, and note the order of the suggestion list before mentioning anyone.
   2. In a new comment, type @<userB> can you take a look?, then start a new line.
   3. On the new line type /request_review @ (type the @, no letters yet).
   4. Confirm @<userB> appears at the TOP of the suggestion list before you type anything, AND that the remaining users keep the same relative order they had in step 3.1 (only @<userB> should have moved).
   5. Repeat with /assign @, /cc @, and /assign_reviewer @, confirming the mentioned user floats to the top each time.
4. Validate ordering by appearance:
   1. Write @<userA> please review, cc @<userB> @<userC>, then start a new line and type /request_review @.
   2. Confirm the mentioned users appear at the top in mention order (userA, then userB, then userC), not alphabetically or in backend order, and the non-mentioned users below them keep their normal order.
5. Validate the trailing-punctuation regression:
   1. Write Thanks @<userB>. (ending with a period).
   2. On a new line type /request_review @ and confirm @<userB> is still floated to the top.
6. Validate code exclusion:
   1. Write a comment with @<userB> inside inline code (wrap it in single backticks), then on a new line type /request_review @, and confirm @<userB> is NOT floated to the top.
   2. Repeat with @<userB> inside a fenced code block (three backticks, newline, the mention, newline, three backticks) and confirm it is also NOT floated.
7. Validate filtering of invalid choices:
   1. Assign @<userB> to the issuable via the sidebar.
   2. In a comment, mention @<userC> (a non-assignee), then on a new line type /unassign @, and confirm @<userC> does NOT appear (only current assignees show).
   3. Type /assign @ and confirm an already-assigned mentioned user is excluded, while a mentioned non-assignee floats to the top.
8. Repeat steps 3, 4, and 6 in the rich text editor (toggle the comment box mode) and confirm identical behavior, paying particular attention in step 3.4 that only the mentioned user moves and the rest of the list keeps its original (alphabetical) order.
9. Validate the no-op cases:
   1. After mentioning someone earlier in the comment, type a plain @ (not preceded by a quick action) and confirm the list is NOT reordered.
   2. In a fresh comment with no prior mentions, type /request_review @ and confirm the list looks normal with no errors.
10. For the same comment content, confirm the Markdown and rich text editors produce the same top-of-list ordering.

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.