feat: server-driven banned/approved mod policy

[ChronoFinale]

What this adds

Server-driven banned/approved mod policy. The server keeps the policy in memory and sends it to a client when it joins/creates a lobby, so the client can colour opponents' mods red (banned) / green (approved) / white (unknown) — and staff can update the lists without a mod release.

This is the game-server piece. The admin UI + source of truth is a companion PR to www (adds GET /api/mod-policy); the client rendering is a companion PR to BalatroMultiplayer.

How it works

• modPolicy.ts — in-memory { banned, approved } with get/set. At boot it loads an optional mod_policy.json fallback, else a minimal hardcoded default. fetchRemotePolicy() pulls the normalized { mods: [...] } array from <BALATROMP_BASE_URL>/api/mod-policy.
• main.ts — a background poll refreshes the cached policy on an interval (no restart). The admin setModPolicy command updates it live and broadcasts to clients in lobbies.
• actionHandlers.ts — sendModPolicy on lobby create / join / rejoin.
• actions.ts — the setModPolicy server→client action type.

The website is the source of truth: staff edit the lists there; the server polls and caches.

Config (.env.example)

• BALATROMP_BASE_URL — defaults to production; override to http://localhost:3000 for local dev.
• MOD_POLICY_REFRESH_MS — poll interval (default 5 min, min 5 s).
• MOD_POLICY_TOKEN — optional bearer token if the endpoint is ever gated.

mod_policy.json is gitignored — it's only a local offline fallback.

Verification

• tsc clean.
• End-to-end locally: edit list on the website → server poll picks it up (~5 s) → setModPolicy delivered to the client on lobby join.