Cap moves returned per move-feed request

[mmiermans]

The move-feed endpoint currently returns every pending move for a game in a single response. For long games this makes the JSON payload large and the polling client only consumes a window of moves at a time anyway.

This adds an optional maxmoves query parameter to getmovefeed.php that caps how many moves are returned, and has the game manager request a fixed batch size (movesPerRequest) on each poll. Behaviour is unchanged when the parameter is absent.

[github-actions]

🤖 Claude has reviewed this PR — expand after forming your own opinion

Code Quality: The variable name $mm is cryptic. Every other variable in getmovefeed.php uses a descriptive name ($move_count, $game_id, $fetchGameStats). Rename to $max_moves for consistency in both getmovefeed.php and movefeed.php.

Security: Negative or zero maxmoves values produce surprising behavior. The (int) cast does not prevent negative numbers. array_slice with a negative length silently removes elements from the end; with length 0 it returns nothing. A client can craft requests that truncate the feed in unintended ways. Guard against this by unsetting the variable when non-positive, or add a > 0 check alongside isset() in movefeed.php.

Performance: Minor — the cap is applied in PHP after the stored procedure returns all rows, so the database still does the full work. Not a concern at current scale, but if game lengths grow significantly, pushing a LIMIT into the stored procedure would avoid transferring unused rows.

Testing: No test coverage for the new parameter (negative values, zero, absent, very large). If there is an integration test suite for this endpoint, consider adding cases for these edge inputs.