Fix(Unit Frames): apply a SharedMedia font that registers after the login build

[dfrisone]

Bug: reported by Discord user @boeckske_agentzero23 in the EllesmereUI bug channel (2026-08-28, on the current release).

Issue: a font loaded through a custom font loader and picked as the general font applies everywhere in the UI except the unit frames, which stay on the fallback face. A bundled EUI font applies normally, and setting the font override on the Unit Frames card instead of the global font makes no difference. Toggling Dark Mode off and on fixes the unit frames for the session, which is the tell: the font resolves correctly by then, so this is timing rather than resolution.

Root cause: the unit frames module keeps the resolved path in a local, cachedFontPath, refreshed only by ResolveFontPath from OnInitialize, ReloadFrames and the options page, and SetFSFont reads it through GetSelectedFont. Every sibling module calls EllesmereUI.GetFontPath at paint time instead, so when a late LibSharedMedia_Registered drops the shared font cache they pick the new face up on their next repaint. Unit frames never re-read, so a SharedMedia pack that registers after the login build, either from a PLAYER_LOGIN handler dispatching later than ours or on demand, leaves only the unit frames on the fallback face until something calls ReloadFrames, which is what the Dark Mode toggle does. Bundled fonts resolve out of FONT_FILES with no SharedMedia involvement, which is why they always worked, and a per-module override fails identically because it walks the same GetFontPath("unitFrames").

Fix: the module registers its own LibSharedMedia_Registered receiver. On a font registration it re-resolves and calls ns.ReloadFrames only when the path changed, so a login with no SharedMedia font in play does no work at all. Two details matter. The check is deferred a tick, because ns.ReloadFrames is assigned from a C_Timer.After(0) inside EnableBody and a registration arriving during the login dispatch would otherwise find it missing; the same tick also puts the check after the core's own receiver, which is what repopulates _smFontPaths. And what it tracks as done is the path last actually repainted, never the module snapshot: ReloadFrames refreshes that snapshot before its own InCombatLockdown return, so after a reload in combat the snapshot would match while nothing had been painted and no retry would ever fire. A rebuild blocked by lockdown re-arms on PLAYER_REGEN_ENABLED through its own frame, the same shape RealiseClassPowerStyle uses a few lines above for the same reason.

Not yet verified in game.