feat: colour opponents' mods by server mod policy

[ChronoFinale]

What this adds

Colours each opponent's mods in the lobby list by the server-driven mod policy: red (banned) / green (approved) / white (unknown). The server sends the policy via a setModPolicy action; unknown mods stay white — we never auto-flag something we can't classify.

This is the client piece. It pairs with:

• BalatroMultiplayerAPI-Server — sends the policy to a client on lobby join.
• www — where staff manage the banned/approved lists (the source of truth).

Changes

• networking/action_handlers.lua — setModPolicy handler sets MP.BANNED_MODS / MP.APPROVED_MODS.
• lib/matchmaking.lua — classify_mod / get_banned_mods match the policy case- and punctuation-insensitively, with version-prefix matching (1.0.0 matches 1.0.0~BETA) and a dash-boundary heuristic so a glued id-version wire string still resolves (e.g. Saturn-0.2.2-E). Approved list mirrors banned. The normalized index is cached per source table.
• ui/lobby/lobby.lua — colour each mod row via classify_mod.
• ui/lobby/start_ready_button.lua — the banned-mods warning text uses light/white (reads better than red on the lobby background).
• core.lua — MP.APPROVED_MODS default fallback.

Notes

• Backwards-compatible policy value semantics (mirrors the server): true = all versions, "1.2.3" = one version, ["1.0","1.1"] = a set.
• Matching is currently punctuation-insensitive; the website treats punctuation as significant, so the client matches slightly more leniently. For real SMODS ids (unique well beyond punctuation) this never produces a wrong match. Tightening the client to match exactly is a trivial follow-up if desired.

Verification

Tested end-to-end locally: edit lists on the website → server polls and pushes setModPolicy on lobby join → opponent mods colour red/green/white in the lobby, with the generic banned-mods warning.