Ban-pick: weighted tuple pool policy per gamemode (Botlatro generation parity)

Inizia individuando l'entry point BP.start del motore ban-pick, il suo pool predefinito attuale e l'integrazione di build_pool/decorate_tile. Usa src/utils/TupleBans.ts come riferimento comportamentale per la generazione di tuple pesate e dei vincoli. Il lavoro è completo quando le policy dei consumer funzionano per mod e gamemode, con una configurazione distribuibile dal server e valori predefiniti del client come descritto.

The ban-pick engine's default pool is a uniform random sample of every installed deck Back — including modded decks — with no exclusions, no weights, and no stake dimension. Botlatro (the Discord matchmaking bot) already runs real pool policy for its tuple-ban queues; this issue is about giving consumer mods the same power in-game, per mod and per gamemode.

Reference: what Botlatro's generation enforces (src/utils/TupleBans.ts)

• Allowed stakes: a fixed subset (White/Green/Black/Purple/Gold — 5 of 8).
• Allowed decks: decks table minus per-queue banned_decks minus match-step bans.
• Weighted roulette-wheel selection via per-queue deck_mults / stake_mults.
• Occurrence caps in the generated list (9 tuples): max 4 of any stake (< (tupleCount-1)/2), max 3 of any deck (< (tupleCount-3)/2), no duplicate (deck, stake) pairs.
• White-stake guarantee: if the final slot is reached with zero whites, it is forced white — every list contains at least one.
• All of it is data-driven (DB tables) so moderators tune weights/bans live, without a deploy.

Proposal

1. A reusable weighted-tuple pool helper in the API (opt-in, e.g. MPAPI.BanPick.build_weighted_pool(policy)), implementing the constraints above and returning { key, stake } items. The engine already supports everything downstream of it: pool items may be { key, stake, ... } tables, and config.decorate_tile(card, item) renders stake stickers — no engine changes needed.
2. Policy comes from the consumer, per gamemode — each mod passes its own policy into BP.start via build_pool, exactly like schedule/decorate_tile today. PvP and Speedrun configure independently.
3. Policy data should be server-deliverable (gamemode config in the match/lobby payload, keyed by modId + gameMode) so allowed lists/weights can be tuned like the bot's DB-backed mults — without shipping mod updates. Client-side defaults as fallback.

Notes

• Sampling differs today: the in-game default samples decks without replacement (each deck once); tuple pools intentionally allow one deck at multiple stakes. Both remain valid choices per gamemode — the helper covers the tuple case, the current default stays for plain drafts.
• Related: the low-rated-player pool veto (see linked issue) depends on this — its mercy rule ("force white stakes into the reroll") only has meaning against a weighted tuple pool.