fix(blizzskin): distinguish disabled quest buttons

[0x963D]

What does this PR do?

Quest action buttons now use the existing state-aware label styling, so unavailable Accept/Next/Continue actions render gray while enabled actions remain white.

This keeps the existing flat button skin and Blizzard font while making the interaction state readable without requiring hover.

Fixes #1173

How was it tested?

• Lua 5.1 parse with luaparse 0.3.1.
• ASCII-only diff and clean locale-key check.
• Retail: exercised the real QuestFrameAcceptButton as an isolated specimen; disabled rendered gray and enabled rendered white, then restored its parent, anchor, scale, text, visibility, and enabled state.
• 12.1 PTR: repeated the same disabled/enabled transition on the real Blizzard button after a reload; behavior matched Retail and the button state was restored.
• No new events, frames, timers, hooks, or client branches.

Screenshots

Matched Retail captures of the same Blizzard action button at the same position and UI scale. Disabled is left; enabled is right:

Checklist

• New settings default OFF (N/A: no new setting)
• Zero cost while disabled: no events registered, no polling, no hooks doing work, no frames built (N/A: no optional runtime)
• Cheap while enabled: event-driven (no polling, no timer-based logic, no per-frame allocations) (N/A: no optional runtime)
• No writes onto Blizzard-owned frames (weak-table pattern used); HookScript/hooksecurefunc only, never SetScript on Blizzard frames (uses the existing state-label helper; no new scripts or direct frame mutation path)
• Tested in-game, works on live retail; no load errors on the 12.1 PTR client