Fix wildcard ChestShop empty-variant menu slot collision when selling

Selling to a wildcard ChestShop sign on staging showed an internal error. The live log at 2026-10-24 14:55:13 UTC records IllegalArgumentException: Slot already occupied: 22 in MenuView.Builder.slot → ShopVariantsMenu.choices:38 → PlayerInteractListener.onInteract:242.

Affected build: chestshop-2026.10.49.1-dev-g63a3c8f29e9c.jar, HE commit 63a3c8f29e9c71603e72def6e0880c1682d24cbf, Paper 26.3 build 206; deployed after PR #101.

Cause

ShopVariantsMenu.choices always reserves content slots 0–44, even for an empty variants list. Its empty branch then adds the empty-state barrier at fixed slot 22. Inspection of the actual installed MenuView.Builder bytecode confirms content() reserves the whole range even with zero items, and slot() rejects any reserved content slot. Therefore the intended empty-state screen deterministically throws.

ShopVariantsService.choices searches the player's inventory for selling and the connected shop inventory for buying. The observed stack reached the empty-list branch. Why this particular player's items produced no variants was not independently established; do not assume the matcher is correct or broken from this exception alone.

Reproduction

1. Open an otherwise permitted wildcard sign using the sell interaction with no matching variants in the player inventory (respect reverse-buttons configuration).
2. The variant-selection menu attempts to render its empty state.
3. Observe internal error instead of a usable empty-state/cancel menu. Also exercise buying from a wildcard shop with no matching stock.

Expected fix and acceptance

• Build the empty layout without reserving slot 22 as content, or use a non-overlapping empty-state design; retain the framework's collision guard.
• Exercise the real menu builder in regression tests: zero variants must render without exception, show the empty message, and preserve cancel behavior.
• Cover 1, 45 and 46+ variants, paging controls, buying/selling and reverse-buttons configuration.
• Verify no trade, item movement or money change occurs merely from rendering/cancelling the empty menu.
• Recheck matching items versus the actual wildcard pattern in authenticated staging gameplay, then verify a populated selection can proceed to confirmation.

Evidence: live stack and exact deployed source inspected; framework behavior checked in installed jar. No fix, reproduction transaction, DB mutation or additional deployment performed.

Related feature: PAR-507. Source: ShopVariantsMenu at deployed commit, ShopVariantsService.