refactor(test): use AutoMapper in test utilities

[coderabbitai]

Description

Currently, the test utilities in PlayerFakes.cs use manual mapping to create request and response models. Since we've migrated to AutoMapper for model mapping in the main codebase, we should also utilize AutoMapper in the test utilities for consistency.

Background

This issue originated from a code review comment in PR #194:
#194 (comment)

Proposed Changes

• Add AutoMapper configuration to test project if not already available
• Refactor manual mapping methods in PlayerFakes.cs to use AutoMapper
• Ensure proper testing of AutoMapper configuration validity

Example Implementation

Instead of manually mapping properties like this:

public static PlayerResponseModel CreateResponseModelForOneNew()
{
    var player = CreateOneNew();
    return new PlayerResponseModel
    {
        Id = player.Id,
        FullName = $"{player.FirstName} {(string.IsNullOrWhiteSpace(player.MiddleName) ? "" : player.MiddleName + " ")}{player.LastName}".Trim(),
        // Other properties...
    };
}

We could use AutoMapper:

public static PlayerResponseModel CreateResponseModelForOneNew() =>
    Mapper.Map<PlayerResponseModel>(CreateOneNew());

This would reduce code duplication and ensure mapping consistency between production and test code.

[nanotaboada]

We decided not to use AutoMapper in the test project to maintain clarity, isolation, and reliability in our tests.

• Tests should validate our application logic, not rely on the correctness of third-party libraries like AutoMapper.

• Using AutoMapper in tests introduces unnecessary indirection and hides the actual structure of the data, making test failures harder to diagnose.

• Mapping issues should be tested separately, in dedicated mapping tests (e.g., validating MapperConfiguration), not in unit tests for controllers or services.

• Our current approach using explicit factory methods (e.g., the MakeRequestModelForCreate) provides better readability, flexibility, and maintainability.