Expand test coverage for the implementation-first GraphQL migration #137

Context

The GraphQL implementation-first migration (issue history on fix/116-add-pagination-to-nested-list-fields) added or changed several fields without corresponding test coverage. Priority gaps identified while auditing the migration:

Tasks

1. Filtering/sorting on matchesByBracket and participants

Both fields carry [UseFiltering][UseSorting] (added as part of the Bracket/Tournament implementation-first migration), but no test exercises either capability — e.g. filtering matches by round, sorting participants by slotNumber, filtering participants by a nested participant field. Add coverage confirming these actually narrow/order results, not just that the connection shape parses.

2. ApplicationUser schema allow-list regression test

ApplicationUser : IdentityUser<int> inherits ~13 members from a third-party base (PasswordHash, SecurityStamp, ConcurrencyStamp, lockout fields, etc.) that must stay hidden — currently enforced only by an explicit Ignore(...) list in ApplicationUserResolvers.Configure, with no automated check that the list stays complete as HotChocolate/Identity versions change. Add a test (likely in TournamentAPI.UnitTests, schema-introspection based) asserting ApplicationUser's field set is exactly {id, firstName, lastName, isEmailPublic, email} — turns a silent leak into a loud, automated failure.

3. N+1 / batching spot-check

The whole point of routing Player1/Player2/Winner/Owner/Participant/Tournament through DataLoaders (ApplicationUserService, TournamentLookupService, etc.) instead of implicit navigation properties is to batch them into one query per field per page rather than one query per row. No test currently confirms this. Add an integration test that, given a bracket with multiple matches (or a tournament with multiple participants), asserts the resolved field is served via a single batched SELECT ... WHERE Id IN (...) — e.g. via an EF DbCommandInterceptor/logging assertion — rather than one query per row.