Add social_id ban list

[KarmicP]

A ban list that survives restarts, stored against the player's social_id — the account id the engine gives us (a Steam ID on Steam builds). It doesn't change when someone renames or reconnects from a new address, so those two ways round a ban don't work.

Draft, because there are two questions at the bottom I'd rather ask than guess at. Happy to change anything.

What it does

Three admin commands next to boot, same permissions:

• ban <client num> [reason] — bans and removes the player
• unban <social_id> — lifts a ban
• banlist — lists current bans

Bans live in baseq2/bans.cfg, one per line as social_id|name|reason. Read at startup, rewritten on change (via a temp file, so an interrupted write can't corrupt it). Only the id matters; the name is there for readability. Comments you add by hand won't survive a rewrite.

Bots and unauthenticated players have no social_id, so they can't be banned — ban says so and kicks instead.

Most of the code is three new files under src/sgame/muffmode/; the record handling is engine-free and covered by 7 new offline tests (suite goes 60 → 67, all passing). The rest is small: load at startup, a check at the top of ClientConnect, and the commands.

A boot fix, in its own commit

The engine's kick wants a lobby user number, but boot passed the entity index — always exactly one higher, since P_GetLobbyUserNum is (player - g_entities) - 1. So boot 3 acted on the next slot along, and on an empty slot the engine could call into client code with no client attached. Your own bot_utils.cpp:182 already sets lobby_usernum from P_GetLobbyUserNum.

I hit this because ban also kicks and I didn't want to copy the bug into new code. It's a separate commit with its own changelog entry — revert that one commit and the ban list is unaffected. Happy to split it into its own PR instead.

What it can't do

Refusing the connection doesn't get a banned player out of lobby chat, because the chat connection is set up before ClientConnect runs. They can keep talking until their join attempt times out — 15–20 seconds when I tested.

So the check also kicks them from the lobby, which cuts that to a frame or two. It doesn't close it completely: the chat connection exists before any game code runs and there's no hook for it, so a determined player still gets a moment per attempt. That needs an engine-side fix, which I can't reach.

Two questions

1. ban picks its target differently from boot. It takes a client number and reads it directly, rather than going through ClientEntFromString. That helper checks for an exact name match first, so a player named 3 gets picked up by ban 3 instead of whoever is in slot 3. For boot that's a passing annoyance; for ban it writes the wrong person's id to disk. I've left boot alone — unlike the kick bug, that's a judgement call and yours to make. Happy to align them either way.

2. Where should this live on main? You already store profiles by social_id there, so folding bans in is an obvious alternative to a separate file. But mm_client_profile.cpp strips a leftover banned field alongside admin, under a comment about authority coming only from the authenticated admin system — which reads like a deliberate choice to keep ban status out of that file. You know why that code is there and I don't, so I'd rather ask. I'll match whichever you prefer when I port this.

Base

0.60-stable at v0.60.20 (3621fee). All new code apart from the one boot line: 480 added, 1 removed. Builds with MSVC, offline tests pass.