fix(actionbars): only reveal empty slots when the drag can actually pick up

[dfrisone]

The report

Reported by @WildKab on 8.7.6, a follow-on to the empty-slot fix in that release. With action bars locked, left-click-dragging a spell lights up the empty-slot boxes on every bar, and they stay there for 5-15 seconds, or until the spell is used, or until it is actually moved with shift.

Cause

The combat-drag belt wraps OnDragStart on every button and set the transient grid bit unconditionally:

ActionButtonController:WrapScript(btn, "OnDragStart", [[
    control:RunAttribute("SetShowGrid", true, 2)
]])

OnDragStart fires on the gesture, not on a successful pickup. Blizzard's own ActionBarActionButtonMixin:OnDragStart checks Settings.GetValue("lockActionBars") and IsModifiedClick("PICKUPACTION") and no-ops when the bars are locked without the modifier.

So a plain left-drag over a locked bar turned the grid on with no pickup behind it. With no pickup there is no ACTIONBAR_HIDEGRID, so the wrapper's assumption that "the matching grid-off arrives via the monitor or, failing that, the regen apply" never came true on this path.

That accounts for all three ways the reporter saw it clear:

• Shift-drag is a real pickup, so it produces a real SHOWGRID/HIDEGRID pair.
• Using the spell forces a repaint.
• 5-15 seconds is however long until some unrelated grid event lands.

This is not a regression of the 8.7.6 fix. That one was about the showgrid reason bitmask, where bit 1 is Blizzard's own CVAR reason so the transient test had to become >= 2 rather than > 0. Same subsystem, different cause.

Fix

Mirror Blizzard's own condition inside the snippet, so the reveal only fires when the drag will actually pick the action up.

IsModifiedClick is available in the restricted environment: it is in DIRECT_MACRO_CONDITIONAL_NAMES, copied into RESTRICTED_FUNCTIONS_SCOPE at Blizzard_RestrictedAddOnEnvironment/RestrictedEnvironment.lua:97, and SecureHandlers.lua ships in that same addon.

The lock setting cannot be read in there, so it rides in as an eab-barslocked attribute on the controller, synced at setup, on PLAYER_ENTERING_WORLD, and on CVAR_UPDATE (name-filtered) and PLAYER_REGEN_ENABLED for a lock toggled during combat.

Fails open. An unseeded or stale attribute reads as "not locked" and you get the previous unconditional reveal, so the combat-drag fix cannot regress into being worse than today.

Notes for review

• Third commit is a self-review pass. It fixes a real seed-path defect: Settings.GetValue returning nil was accepted as "not locked" because only the pcall status was checked, and the seed runs inside FinishSetup, which can execute before that setting is registered.
• The write to the controller attribute is guarded on change, since SetAttribute re-runs the controller's _onattributechanged snippet. That snippet only acts on name == "flush", so the new attribute is otherwise inert there.
• No new chunk-level locals; this file is at Lua 5.1's 200-local cap.
• luac -p clean.