Design a data structure that simulates a sequence of rooms where players solve tasks and may move only to the next room once they finish the current one. You will process a list of `operations` and return the outputs of the query operations in order. Implement a function `solution(operations)` that processes the following operation tuples: - `('addPlayer', id)` — register a new player. Each player starts in room `0` with a total score of `0`. Adding an existing id is a no-op (idempotent). - `('recordTask', playerId, roomId, points)` — award `points` to the player **only if** `roomId` equals the player's current room (you cannot score in a room you have already left or not yet reached). The points add to the player's running total across all rooms. - `('moveToNextRoom', playerId)` — advance the player to the next room (increment their room index by 1). - `('getPlayerState', playerId)` — append `{'room': r, 'score': s}` to the result list. If the player does not exist, append `None`. - `('topK', k)` — append a list of the `k` player ids with the highest total scores at query time, highest first. Break ties by smaller id. If fewer than `k` players exist, return all of them. Return the list of outputs produced by `getPlayerState` and `topK`, in the order they were called. **Leaderboard requirement:** keep `topK` efficient as scores update. Because a binary heap cannot update a key in place, a naive re-push leaves duplicate (stale) entries for the same player. Prevent duplicates using lazy deletion with version stamps: every score change bumps the player's version and pushes a fresh `(-score, id, version)` entry; at query time pop entries whose version no longer matches the player's current version and discard them. **Example:** `addPlayer 1`, `addPlayer 2`, `recordTask 1 0 50`, `recordTask 2 0 30`, `getPlayerState 1`, `topK 2` returns `[{'room': 0, 'score': 50}, [1, 2]]`.