feature: anti-wallhack match option and status tracking

[Flegma]

API side of the CS2FOW anti-wallhack integration.

• match_options.anti_wallhack (boolean, not null, default true): existing tournaments and league seasons inherit protection via their match_options rows
• match_maps.anti_wallhack_active (nullable boolean): observed per-map state reported by the game server at go-live
• current-match payload serves the option ANDed with the anti_wallhack_enabled settings kill switch (seeded true; missing row = enabled)
• new antiWallhackStatus event processor writes the per-map state
• Hasura permissions mirror knife_round; anti_wallhack_active is client read-only

PRE-MERGE CHECKPOINT: regenerate genql types against the real dev Hasura (Task 11 codegen ran against an ephemeral stack; restores unrelated stale-main drift and the generated client default URL).

Design: docs/plans/2026-07-09-cs2fow-anti-wallhack-design.md (5stack local docs)
Part 2 of 3; merge after game-server PR #162, before the web PR.

[Flegma]

Max-effort code review completed on the rebased branch (10 finder angles, adversarial verification, gap sweep). Confirmed findings fixed in a9b078a:

1. update_match_options_best_of.sql: while adding anti_wallhack earlier, the review found the function was already silently dropping four other real, permissioned columns (auto_cancellation, match_mode, auto_cancel_duration, live_match_timeout). Column lists completed to 24/24 matching clone_match_options.sql. Note: this function currently has zero callers (the live decider path routes through clone_match_options_with_best_of -> clone_match_options); completing it prevents the bug re-firing if revived.
2. Kill-switch parsing hardened: the read now trims/lowercases the settings value, so a console-edited "False" or "false " disables correctly. No admin UI writes this row yet, so the Hasura-console path is the realistic incident-response route.
3. The new SQL test's information_schema query now qualifies table_schema = 'public'.

IMPORTANT for anyone who ran this branch BEFORE the mono-repo rebase against a persistent database: the anti-wallhack migrations were renumbered from 1870000000000/1870000000100 to 1871000000000/1871000000100 because upstream's plugin_runtimes migration took 1870000000000. A DB that applied the OLD numbering has a stale schema_migrations row that will silently skip plugin_runtimes and then crash-loop on the enums pass with "relation e_plugin_runtimes does not exist". Remediation: DELETE FROM hdb_catalog.schema_migrations WHERE version = '1870000000000'; then restart so plugin_runtimes applies. No known environment ran the old numbering (the dev stack was down throughout), but flagging for safety. This was empirically reproduced during review.

Systemic notes for the maintainer (pre-existing, not changed here):

• The migration runner dedups by numeric version only, with no content-hash check (unlike the enums/functions/views path); version reuse is a silent-skip footgun.
• The events gateway writes its dedup-cache entry before the processor runs and processor rejections are not caught per-event, so a transient Hasura failure during any event write is silently absorbed within the 10s dedup TTL. All processors share this; the new antiWallhackStatus event just also flows through it.
• Match-creation paths with hardcoded option literals (steam-match-history import, matchmaking, scrims) leave anti_wallhack at DB default true, meaning protection-on for all of them; deliberate blanket default, flagging for explicit sign-off.