feat(qol): hold Artisan payouts at shard cap

[0x963D]

What does this PR do?

Adds an opt-in Hold Capped Artisan Payouts setting under Auto Open Containers.

When enabled, Artisan's Consortium Payouts (item 246585) stay closed while Shard of Dundun (currency 3376) is at its total maximum. Automatic opening resumes after shards are spent. All other containers keep the existing behavior.

The setting defaults off and targets only this known payout/currency pair.

How was it tested?

• Lua 5.1 parse with luaparse 0.3.1.
• ASCII-only diff, git diff --check, and clean locale-key check.
• Retail: verified the setting appears under the existing Auto Open Containers gear menu, defaults off, applies live, registers CURRENCY_DISPLAY_UPDATE only while enabled, and unregisters it after restoring the setting.
• 12.1 PTR: repeated the default-off, live-apply, event-registration, and restore checks after a reload.
• Static proof: only item 246585 reaches the currency-cap query; no new frames, hooks, timers, loops, OnUpdate handlers, allocations, or client branches.

The exact capped-bag-slot hold could not be naturally exercised because neither test character simultaneously had a payout container and capped Shard of Dundun. The item/currency IDs and both client APIs were verified.

Screenshots

Retail problem evidence: Shard of Dundun at its 8/8 total cap (left), with five Artisan's Consortium Payouts ready to open (right):

Checklist

• New settings default OFF (no behavior change without opt-in)
• Zero cost while disabled: no events registered, no polling, no hooks doing work, no frames built
• Cheap while enabled: event-driven (no polling, no timer-based logic, no per-frame allocations)
• No writes onto Blizzard-owned frames (weak-table pattern used); HookScript/hooksecurefunc only, never SetScript on Blizzard frames (N/A: no Blizzard-frame mutation)
• Tested in-game, works on live retail; no load errors on the 12.1 PTR client