feat(gaming): review queue for imported games

[okapitula]

Summary

Games a catalogue sync imports now wait in a review queue until an admin approves them, unless their provider is trusted to auto-approve new games. Admins get a queue filter, single and bulk approve/decline, pending counts per provider and in the catalogue stats, and the admin provider list can be loaded for a set of provider ids in one request.

Why

An aggregator sync can add hundreds of games at once, and until now a synced game could go live with nobody having looked at it. The gate has to live in core because the lobby, the bulk set-active paths and the provider admin all sit here: a game.review_status column with a database check (is_active implies approved or auto-approved) is the only place that stops an unreviewed game going live through every path. A consumer could not add that without forking core's tables. The state is aggregator-agnostic, so any importer uses it the same way.

What changes:

• game.review_status (pending, auto_approved, approved, declined) and reviewed_at; game_provider.auto_approve_new_games, off by default.
• POST /backoffice/gaming/games/{id}/review and POST /backoffice/gaming/games/bulk/review (by game ids or provider ids, capped at 5,000 matched games). Approving also enables the game in the same transaction; declining writes only the review columns. Provider scope moves available pending games only.
• Enabling a pending or declined game by id approves it; a provider-scope enable skips them and reports reviewSkippedCount.
• The game PATCH can approve; the provider PATCH sets autoApproveNewGames.
• The admin game list filters on reviewStatuses; provider detail and list carry pendingReviewCount; the provider list takes an optional ids filter; catalogue stats carry games.pendingReview and providers.autoApprove.
• New events gaming.games.reviewed and gaming.games.auto_approved, both written to the audit log.
• initialGameReviewState(autoApprove, now) gives an importer the review columns for a new game.

Alternatives considered

• Keeping new games inactive and treating "inactive" as "unreviewed": it can't tell a game an admin switched off from one nobody has looked at, and any enable path would put an unreviewed game live.
• A reviewed_by column: the audit record already holds the actor, so it would duplicate it.
• Applying auto-approve retroactively when a provider is switched on: it would approve games a sync imported before the provider was trusted, so it only applies to games imported afterwards.

Risks

• Migrations 0015–0017 add the review columns, backfill existing games as approved, then switch new rows to pending, add a check that keeps unapproved games inactive, and add two indexes. 0015 holds a lock on game through its check scan and partial index build, and 0017 blocks writes to game while it builds the second index; both windows grow with catalogue size.
• During a rolling deploy, an old instance that enables a game the new importer just inserted as pending gets a check-constraint error. It fails safe and stops once old instances drain.
• gaming.provider.* snapshots gain autoApproveNewGames; older events replay it as false.
• Importers must set new games' columns from initialGameReviewState(...), read the provider's auto-approve flag in the insert transaction, call notifyGamesCreated after commit, and emit gaming.games.auto_approved once when they put an auto-approved game live.