Locking a previously completed tile makes player and admin bingo results disagree

src/routes/bingo/+page.server.ts と src/routes/admin/users/[id]/+page.server.ts のタイル処理を比較し、その後 src/lib/server/standings.ts を調査します。Issue に記載された非アクティブなタイルのシナリオを再現し、以前にマークされたロック済みタイルに対する意図されたポリシーを判断します。完了とは、プレイヤーボード、順位表、管理者の検出、検証、およびあらゆるリセット状態が、文書化された 1 つのポリシーに一貫して従うことを意味します。

Problem

Inactive tiles are treated inconsistently after a player has already marked one. The player board and loadStandings count completed.has(tile.id) regardless of isActive, but the admin review loadBingoState explicitly skips every inactive tile before detecting bingo.

Consequently, if an administrator locks a tile after players marked it, a player can still see a winning line while the administrator sees no bingo and cannot verify it. The leaderboard uses the player behavior rather than the review behavior.

Reproduction

1. Let a player mark a tile that is part of a potential winning row.
2. In /admin/tiles, change that tile to inactive.
3. Complete the rest of that row.
4. The player board counts the old mark and can show BINGO, but /admin/users/:id omits it from detection and the verify action rejects the claim.

Suggested fix

Choose and document one policy for progress on locked tiles. If old progress remains valid, remove the !t.isActive skip from admin detection. If locking is meant to invalidate progress, apply the same rule in the player board and standings, and address verification/reset state consistently.

Affected code

• src/routes/bingo/+page.server.ts
• src/routes/admin/users/[id]/+page.server.ts
• src/lib/server/standings.ts