feat: let a custom game mode define its own team size

[LCrew]

Why

A match's player count comes from match_options.type alone, and that fact is hard-coded in four places that have to be kept in sync:

Where	Values
get_match_type_min_players()	per lineup 5 / 2 / 1
tbi_draft_games	capacity 10 / 4 / 2
ExpectedPlayers (api)	total 10 / 4 / 2
GetExpectedPlayerCount() (plugin)	total 10 / 4 / 2

A custom game mode can already change the plugins and cvars a match runs under, but not its shape — so a 3v3 retakes mode still demands a full 5v5 lobby, and the draft room's Start button stays locked until 10 people are seated.

What

game_modes gains players_per_team and allow_short_handed_start.

One new resolver, get_match_options_min_players(mo), coalesces the size a match actually launched at → the mode's → the type's. Every gate that keyed on the type now reads it instead: match_min/max_players_per_lineup, check_match_has_min_players, is_match_lineup_ready, the match_lineup_players removal trigger, and draft_games capacity.

A mode may also permit starting a draft lobby before both sides are full. The new startDraftGame action narrows the lobby to the players who turned up before flipping it to Filled — the other order leaves a draft stuck in CreatingMatch that beginDraft then refuses to act on, with every player in it locked out of joining anything else. Authorization is unchanged: isOrganizerOrHost matches is_draft_game_organizer exactly.

Two snapshots, because one number can't describe an uneven start

column	records	why
min_players_per_lineup	the smaller side	the gates apply one number to both lineups, so a 1v2 has to record 1 or the short side never clears
expected_players	the total	what the game server waits for; a 1v2 needs 3, and doubling the above gives 2

Both count starters only, read off draft_game_players rather than the match lineups — buildTeams also seats waitlisted backups in substitute slots, and a backup isn't someone warmup should wait for. Captains still requires an even pool, because get_draft_game_pattern builds its pick order off capacity / 2.

Zero change by default

Every column is nullable. With no custom mode configured, each path resolves to exactly what the type gave before:

case	resolves to
Competitive, no mode	5
Wingman, no mode	2
mode with players_per_team = NULL	5
mode with players_per_team = 3	3

Inert until an admin sets players_per_team; clearing it back to NULL is a kill switch needing no deploy.

Tested

• Deployed to a live install with attached game servers. A mode with players_per_team = 1 produces a 1v1 lobby, sends 2 players, and the game server goes to [0/2] instead of [0/4].
• 844 unit tests, and integration tests across the draft, game-mode, match-lifecycle, match-options and migration suites.
• SQL gates exercised against a real Postgres: resolver precedence, capacity derivation, and every start gate — a 3v2 starts, 2v0 is refused, captains-odd is refused, and uneven-on-a-normal-mode is still refused.

Notes for review

• generated/ covers the first three columns but not expected_players — worth a yarn codegen against a Hasura carrying the migrations. Related: the current-match selection in matches.controller.ts turns out not to be type-checked at all (a deliberately bogus field compiles), so column names there are only validated at runtime. Might be worth a look independently of this PR.
• Rollback doesn't need the down-migrations: hasura/functions and triggers re-apply whenever a file's SHA changes and are all CREATE OR REPLACE, so reverting the code restores the old definitions on the next boot. The migrations are additive and safe to leave.
• Part of a three-repo change. Merge order: this → web → game-server.