refactor: split ServerMultiplayerRoomMixin into three focused mixins

[xpoes123]

The ~477-line ServerMultiplayerRoomMixin in server/multiplayer/ServerMultiplayerRoomMixin.js combined message routing, connection handling, room settings, ban/kick management, and votekick logic in a single class body, making each concern harder to locate and reason about. This is a behavior-preserving structural refactor that splits those concerns into three focused mixins without changing any method body.

Problem

ServerMultiplayerRoomMixin had grown to the point where unrelated concerns — ban timers, votekick thresholds, and a dozen toggle*/set* settings guards — were interleaved with connection and game-flow logic. There were no clear boundaries and no way to read or test one concern in isolation.

Changes

• server/multiplayer/BanKickMixin.js — new file; contains ban and cleanupExpiredBansAndKicks. BAN_DURATION constant moves here.
• server/multiplayer/VotekickMixin.js — new file; contains votekickInit and votekickVote.
• server/multiplayer/RoomSettingsMixin.js — new file; contains allowed, all set* methods, and all toggle* methods.
• server/multiplayer/ServerMultiplayerRoomMixin.js — the three new mixins are composed via BanKickMixin(RoomSettingsMixin(VotekickMixin(RoomClass))) at the class definition. The moved methods and BAN_DURATION are removed. The constructor, connection handling, and game-flow logic are unchanged. MODE_ENUM import is removed (now only used inside RoomSettingsMixin); isAppropriateString is likewise moved to RoomSettingsMixin.

All method bodies were moved verbatim. Consumer files (ServerTossupRoom, ServerTossupBonusRoom) are untouched — the export name and (RoomClass) => ... call signature are identical.

Risk & testing

This is behavior-preserving by construction: all mixins extend the same prototype chain of the same instance, so this, instance state, cross-method calls, and every super. call resolve identically to before. The single constructor remains in ServerMultiplayerRoomMixin so initialization runs once in the same order. Every method from the original class is present exactly once across the four files.

Verified by inspection and static member-presence check. The repository has no multiplayer integration tests, so a live smoke-test is recommended before merging: join a room, buzz, answer, advance to the next question, and exercise ban, kick, and votekick against a second connected client.