localize the middle-click micro menu (and let it use the chosen font)

[labrie75]

What does this PR do?

The middle-click micro menu on the minimap renders its entries in English on every client, because the labels are drawn straight from the item table:

label:SetText(item.text)

Wrapping that one call in EllesmereUI.L(...) sends the labels through the locale system like the rest of the options UI:

label:SetText(EllesmereUI.L(item.text))

Two call sites. The same two entries also hardcoded the Western font, which has no CJK glyphs -- so translating the labels alone renders them as boxes on a Korean or Chinese client:

label:SetFont("Fonts\\FRIZQT__.TTF", 11, "")

That now resolves the user's chosen minimap font first, exactly the way the rest of this file already does, and falls back to the old hardcoded path when none is set:

label:SetFont((EllesmereUI.GetFontPath and EllesmereUI.GetFontPath("minimap"))
                    or "Fonts\\FRIZQT__.TTF", 11, "")

Four lines total, no other change.

This is a separate path from #1133: that PR fixes MakeFont, which the options widgets go through. These two labels are built with a bare CreateFontString and set their own face, so they never reach that helper and stay on the bundled font no matter what the user picks.

Every one of these keys already exists in the locale files -- Character, Talents, Professions, Group Finder, Adventure Guide, Achievements, Collections, Quest Log, Friends, Guild, Housing, Calendar, Game Menu, Shop, Support. They are shared with the options panel, so this one-line change turns the whole menu over to every translated language at once: no locale file is touched by this PR, and nothing needs re-translating.

The secure passthrough buttons still build their frame names from the untranslated item.text:

local btnName = "EUI_MicroMenu_" .. item.text:gsub("%s", "")

That line is deliberately left alone, so global frame names stay English and identical on every client -- only the visible FontString is localized. On an enUS client L() returns the key unchanged, so the menu is byte-identical to today.

Locales/_keys.txt needs no regeneration: the argument is a variable, which extract-locale-keys.sh does not (and cannot) pick up statically. I verified this by running the same grep the script uses against the minimap folder -- the change adds no literal keys.

How was it tested?

Tested in game on live retail with a koKR client: the middle-click menu shows every entry translated, the labels render in the chosen minimap font instead of boxes, the entries still open their Blizzard panels (secure passthrough unaffected), and the menu closes as before. Also checked that no new global frame names appear, and re-ran the extractor's grep to confirm _keys.txt is unchanged.

Screenshots

Before / after on a koKR client:

Checklist

• New settings default OFF -- n/a, this PR adds no setting; it is a pure localization fix with no behavior change (on enUS the rendered text is identical)
• Zero cost while disabled -- n/a; no events, timers or frames added
• Cheap while enabled -- one table lookup per menu entry, once when the menu is built
• No writes onto Blizzard-owned frames -- the change only sets text on EllesmereUI's own FontStrings
• Tested in-game, works on live retail; no load errors (not separately run on 12.1 PTR)