fix(unitframes): retry the Player Aura Bars unlock registration

[dfrisone]

Reported by @|Me-Galois|<ε (Unlock Mode, 8.9.4). After a login or /reload the
player buff frame behaves as though it still has to be placed through Blizzard
Edit Mode, and the EUI buff styling is not applied. Toggling Use Blizzard
Buffs on and back off restores both, until the next reload.

Why the workaround is the clue

Nothing persistent differs either side of it. The setter stores
v and true or nil, so toggling on then off returns the value to nil, exactly
what it already was. No saved state changes, which is why no amount of settings
fiddling helps and why it resets every session.

What the toggle actually does is call PAB_ApplyUseBlizzard(), which re-runs
CreateBars() and the unlock registration -- late enough to succeed.

Root cause

RegisterPABUnlock and RegisterPABCustomUnlock both opened with:

if not (EllesmereUI and EllesmereUI.RegisterUnlockElements and EllesmereUI.MakeUnlockElement) then return end

That API is published from another file and can arrive after CreateBars has
already run. The bail was silent and nothing re-drove it, so no mover was built
for the whole session and the frame read as Blizzard-owned.

This file already handles the sibling race: TryCreateBars retries on a capped
backoff because ns.db lands a frame after PLAYER_LOGIN. There are two
independent readiness conditions here and only one of them was retried.

That also fits "only on my Mage, other characters on the same profile are fine":
a load-order race turns on init timing, not on saved settings, so it can land
the same way every login on one character and never on another.

Fix

Both registrations now retry on the same capped, once-a-frame pattern the file
already uses. Giving up after the cap stays quiet rather than erroring, since
the API is legitimately absent for the whole session when the module that
publishes it is switched off, and erroring there would spam every login for
those users.

Testing

luac -p clean; house style check clean. Click-tested in game and behaving
correctly. Worth a confirmation from the reporter as well, since the race is
timing-dependent and landed on his character rather than every character.