Fix(PAB): right click cancel aura not working

[JuJuFX-dev]

What does this PR do?

Fixes player buffs on the Player Aura Bars (and classic Unit Frames player buffs) sometimes staying un-cancelable via right-click, in two independent parts.

Click channel repair (AuraKit). AuraKit's ApplyStyleToRegions only ever turned the click channel OFF (for styles without cancelButtons, the nameplate click-eater guard), and SetCancelAuraButtons ran once at button creation only. A style that GAINED cancelButtons on already-created buttons therefore never got them back: toggling a Player Aura Bar's per-bar "Right-Click to Cancel" off and on again, or switching into a profile that has it on, left that bar's buffs permanently un-cancelable until the next /reload. The click channel is symmetric now -- clicks are re-enabled for buttons AuraKit itself turned off (d.akClickOff stamp) and the cancel token is re-applied change-guarded (d.akCancel stamp), both pcall-wrapped with the same deferredRestyles fallback the tooltip/motion passes next to them already use. Covers both consumers of the cancel style, Player Aura Bars and the Unit Frames player buffs.

CursorFreelookStartDelta repair (Player Aura Bars). A second, independent trigger for the same symptom, confirmed by two separate field reports: the client CVar CursorFreelookStartDelta controls how far the cursor must move before a held mouse button counts as camera freelook instead of a click. At 0 (zero movement required), any right-click on an aura icon is claimed for freelook before the release reaches the button -- the click is real, the button just never sees it. Blizzard's own shipped default is 0.001, not 0; players land on 0 via third-party "camera feel" addons/macros (a dedicated community addon, CursorDeltaFix, does exactly this: SetCVar("CursorFreelookStartDelta", 0)) or a manual console tweak, never from anything EllesmereUI does.

SyncCancelCVar() repairs this, it does not nudge it: the CVar is only ever touched when caught sitting at the pathological 0, restored to Blizzard's own 0.001 -- never raised past that, and never touched at all if it sits anywhere else, including a deliberately-tuned non-zero value. It only runs while some right-click-cancelable buff surface is actually live (the default Buffs bar, an enabled custom buff bar, or the classic Unit Frames player-buffs display), so a player who never uses the feature never has this CVar touched at all. Hooked into the three points that already own PAB's live style state: CreateBars (login), RestyleBars (default-bar settings changes), and ReloadCustomBuffBarImpl (custom-bar creation/changes).

A deliberately rejected alternative for the same symptom: switching the cancel click token from "RightButtonUp" to "RightButtonDown" also works around a related but separate WorldFrame-mouselook interaction, but was NOT taken -- a right-click-drag starting on an aura icon would then cancel that buff on press. The token stays "RightButtonUp", matching Blizzard's own AuraButtonMixin.

How was it tested?

Static analysis and luac5.1 -p on both changed files. Blizzard behaviour was verified against the shipped source rather than from memory: AuraButtonSharedMixin:SetCancelAuraButtons (string token, RegisterForClicks), AuraButtonPrivateMixin:OnClick_Intrinsic / CanCancelAuraOnClick (plain OnClick, matches any registered token), the ForbiddenAspects block on the intrinsic AuraButton, and CursorFreelookStartDelta's Blizzard-shipped default (0.001, cross-checked against the client's canonical cvar list).

Screenshots

N/A -- no visual change.

Checklist

• New settings default OFF (no behavior change without opt-in) -- N/A, no new settings; the AuraKit fix makes an existing toggle work live instead of after /reload, and the CVar repair only ever touches players already sitting at the broken 0 value while using a feature that needs the click
• Zero cost while disabled: no events registered, no polling, no hooks doing work, no frames built -- SyncCancelCVar short-circuits immediately if PAB is disabled or no cancel-capable surface is live; the click-channel stamps add zero extra button calls on a steady-state restyle pass
• Cheap while enabled: event-driven (no polling, no timer-based logic, no per-frame allocations) -- both fixes only run on existing settings-apply/login hooks, never per-frame
• No writes onto Blizzard-owned frames (weak-table pattern used); HookScript/hooksecurefunc only, never SetScript on Blizzard frames -- the click-channel state lives in AuraKit's existing weak-keyed side table (bd); the CVar repair calls only the public GetCVar/SetCVar API, no frame writes
• Tested in-game, works on live retail