ActionBars: fix Encounter Bar drifting sideways until Edit Mode reopens

[dfrisone]

Problem

Reported on Discord by @moreON (8.7.4, Unlock Mode section): the Encounter Bar "moves on its own" during play, then snaps back to its proper spot as soon as Blizzard Edit Mode is opened. Video triage showed the zone event crystal widget sitting about 90px left of the Edit Mode position, recurring after each fix.

Root cause (Blizzard layout data, not EUI code)

EUI is fully hands-off the EncounterBar (position is Blizzard-owned since 7.3.5). The drift comes from how Blizzard saves the anchor:

• EncounterBar is a VerticalLayoutFrame that resizes to its widget content (UnitPowerBarAlt.xml).
• When the bar is dragged in Edit Mode, UpdateSystemAnchorInfo stores whatever raw anchor StopMovingOrSizing produced. Near a screen corner that is a corner point such as BOTTOMLEFT. Imported layout strings can carry the same shape.
• Outside Edit Mode, Blizzard's WidgetsLayout only re-centers the bar when it is in its default position. A custom-positioned bar just gets EncounterBar:Layout(), so every content width change re-extends the frame from the pinned corner, shifting the visible widgets by half the width delta (the event widget is ~230 wide, the bare crystal ~45, matching the observed ~90px).
• Edit Mode appears to fix it because RefreshEncounterBar pins EncounterBar.minimumWidth = 230 and re-lays-out, so the bar always looks correct while Edit Mode is open.

Fix

One-shot normalization at ActionBars init (ns.NormalizeEncounterBarAnchors): walk C_EditMode.GetLayouts() and, for every non-preset layout where the EncounterBar system is custom-positioned with a single corner/side anchor to UIParent, rewrite it to the equivalent horizontally centered BOTTOM anchor. Offsets are recomputed against the 230x30 envelope Edit Mode pins while the bar is being placed, so the on-screen position is preserved exactly. Width changes then expand symmetrically and the bar stays put.

Safety properties:

• Runs at most once per session and only writes when a drift-prone anchor actually exists (idempotent: converted anchors are BOTTOM and never match again).
• Defers on Edit Mode data readiness (EDIT_MODE_LAYOUTS_UPDATED) and on combat (PLAYER_REGEN_ENABLED), mirroring the CDM module's SaveLayouts-at-init-only rule.
• Saves through the same combined presets-plus-saved payload convention as ApplyPresetEditMode in EllesmereUI_Profiles.lua.
• Skips presets, two-point anchors, and anchors relative to other frames.

Known limitation: re-dragging the bar in Edit Mode can reintroduce a corner anchor for the rest of that session; it is normalized again at next login.

Testing

• Reporter confirmed in game on a test build (8.7.4-encbar1) that the bar no longer moves and stays where Edit Mode places it.
• Verified locally that accounts with only centered or default anchors are a clean no-op (no layout write).
• luac syntax pass; the helper lives on ns inside a scoped block because the AB main chunk is at the 200-local cap.