fix(unitframes): Player Aura Bars sometimes not loading on login

[JuJuFX-dev]

Bugreport: https://discord.com/channels/585577383847788554/1547821004644946010

What does this PR do?

Fixes Player Aura Bars sometimes not loading on login. The affected player sees Blizzard's default buff frame instead of the PAB default bars, and custom bars (e.g. defensives) do not show at all, with no Lua error. Opening the EllesmereUI options, or any other change that reaches ReloadFrames, brings everything back until the next login. It was reported with BigWigs enabled and went away with BigWigs disabled.

Root cause: the login build hung off a PLAYER_LOGIN handler in EllesmereUIUnitFrames_PlayerAuraBars.lua whose first line was if not ns._eufEnabled then return end. That flag is stamped by EnableBody(), which runs from a different PLAYER_LOGIN handler in EllesmereUIUnitFrames.lua, so the build only worked when that handler had already run. Whenever PAB's handler ran first it stood down silently, with no retry and no error: HideBlizzardPlayerAuras() and the custom bar build both live inside CreateBars(), so neither happened. The only later build path is PAB_ProfileResync() at the tail of ReloadFrames, which is why an options change fixed it.

The fix removes the dependency on handler order instead of patching around it. SetupOptionsPanel(), the point where ns.db is set, now calls ns.PAB_CreateBars() directly, following the existing ns._InitEUIModule() call in the same function. That removes the PAB PLAYER_LOGIN branch, the TryCreateBars retry loop and the ns._eufEnabled stamp. The build lands in the same tick as before (the old first retry ran right after SetupOptionsPanel). A disabled Unit Frames module never runs SetupOptionsPanel, so PAB still stays down there without a separate check.

How was it tested?

Tested in-game on live.

Screenshots

N/A, no visual change beyond the bars showing at login as intended.

Checklist

• New settings default OFF (no behavior change without opt-in): N/A, no new settings
• Zero cost while disabled: no events registered, no polling, no hooks doing work, no frames built
• Cheap while enabled: event-driven (no polling, no timer-based logic, no per-frame allocations); the login retry timer is gone, the build is a single direct call
• No writes onto Blizzard-owned frames (weak-table pattern used); HookScript/hooksecurefunc only, never SetScript on Blizzard frames: N/A, Blizzard frame handling is unchanged
• Tested in-game on live; no version gates or pre-Midnight APIs added