Rate-cap validation matches to one in flight per team (#173)

[razam-sherwani]

Closes #173.

Problem

Every submission scheduled a validation match (SubmissionController.uploadSubmission:144-156) with no throttle — the only submission limit was a cumulative storage quota. During a submission rush that adds one match per upload onto the shared queue, on top of matchmaking.

Fix

Reject the upload with 429 when the team already has a validation match in flight, checked before the file is stored (a rejected upload consumes no storage). One in-flight validation per team is enough — a team waits for the pending result before resubmitting.

The count includes created/scheduling as well as waiting/in_progress, so a match sitting in the create→enqueue window still counts (the shared countTeamQueuedMatchesByLadder omits those two — that gap is noted in #160).

Added countTeamAMatchesByLadderAndStatus: validation matches are created with teamA == teamB and no initiatingTeam, so the existing initiatingTeam-keyed count returns 0 for them — the count has to key on teamA.

Tests

SubmissionControllerIT.secondUploadWhileValidationInFlightIsRejected: first upload 200 + one job enqueued; second while the first is pending → 429, no second submission row, no second job. SubmissionValidationIT and GameMatchServiceIT still green.

Verified locally (no CI here): JDK-17 toolchain, Testcontainers Postgres+RabbitMQ. Independent of #172 and #174.

Note: the issue suggested reusing #160/#171's atomic-upsert budget. Those endpoints aren't built yet; the in-flight count is available today and sufficient. When #160 lands, this can fold into the same budget primitive if desired.

🤖 Generated with Claude Code