Implemented tested endpoints

[CapoMK25]

Brief description

This PR implements a robust state machine for handling battle results in the BattleService. It introduces logic to handle "Odd Man Out" scenarios where players report conflicting results (e.g., Team 1 claims victory while Team 2 also claims victory).

The system now transitions from OPEN to PROCESSING when results conflict, triggering a 2-minute "Final Call" timer. After the timeout, the service resolves the conflict via a majority vote (defaulting to Team 1 in ties) and distributes Raid Tokens. This ensures the integrity of the game economy and prevents "silent agreements" or stuck matches.

Change list

• BattleService: Implemented handleBattleResult with conflict detection and resolveConflict with a majority-vote algorithm.

State Machine: Integrated BattleStatus.PROCESSING to represent matches awaiting a timeout resolution.

Timer Logic: Added a 2-minute setTimeout mechanism to finalize matches that don't reach a natural consensus.

Raid Token Distribution: Refactored generateRaidTokens into a dedicated private method to ensure rewards are only issued upon final verification.

Data & Documentation

Schema Update: Updated BattleSchema with pre-validation middleware to prevent players from being assigned to multiple teams.

JSDocs: Added comprehensive documentation for the BattleService, Battle Schema, BattleStatus Enum, and associated DTOs.

DTO Alignment: Fixed a property mismatch where result was used in the DTO but expected as winnerTeam in the service.

Testing & Quality

Unit Tests: Created battle.service.test.ts using Jest fake timers to verify the full lifecycle of a conflict resolution.

Linting: Resolved ESLint errors regarding empty blocks and unused variables to pass Husky pre-commit hooks.