Refactor to use `Guid` as internal `Id` and `SquadNumber` as public identifier

[nanotaboada]

Description

To improve API design and encapsulate internal identifiers, we'll switch from using long/incremental IDs to Guid as the primary key (Id) for the Player entity. The externally visible and unique identifier will be SquadNumber, aligning with real-world conventions (e.g., tracking numbers in logistics or jersey numbers in sports).

This change improves separation between internal persistence concerns and public API contracts. Using a Guid makes the Id explicitly internal, while SquadNumber is more domain-meaningful for clients.

Suggested Approach

• Replace long Id with Guid Id in the Player entity, with default value set via Guid.NewGuid().
• Retain SquadNumber as a required, unique, externally meaningful identifier.
• Update OnModelCreating:
  • Set .HasKey(p => p.Id) and .Property(p => p.Id).ValueGeneratedOnAdd()
  • Add .HasIndex(p => p.SquadNumber).IsUnique()
• Reset the database and create a new initial migration (for educational purposes).
• Seed logic should continue working, now generating players with Guid IDs.
• Update DELETE endpoints (and others if needed) to use SquadNumber instead of Id for public-facing operations.

Acceptance Criteria

• Player.Id is of type Guid, generated via Guid.NewGuid().
• SquadNumber is unique and used as the public-facing identifier (e.g., in DELETE endpoints).
• Fluent configuration updated accordingly in OnModelCreating.
• A new clean initial EF Core migration exists reflecting the new schema.
• The seeded database works as expected on app startup with the new identifier model.
• Controllers and services updated to rely on SquadNumber in routes and validation, where appropriate.

Resources

• 🔗 Keys - EF Core | Microsoft Learn