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

## 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`

Compare the tile handling in src/routes/bingo/+page.server.ts and src/routes/admin/users/[id]/+page.server.ts, then inspect src/lib/server/standings.ts. Reproduce the inactive-tile scenario described in the issue and determine the intended policy for previously marked locked tiles. Done means the player board, standings, admin detection, verification, and any reset state consistently follow one documented policy.

Written by the indexing model from the issue text.