Add `.github/copilot-instructions.md` to guide GitHub Copilot behavior

[nanotaboada]

Description

The repository would benefit from a baseline .github/copilot-instructions.md file to guide GitHub Copilot's suggestions. This ensures generated code aligns with our current stack, architecture, and coding practices, even in this proof-of-concept phase.

By explicitly defining what Copilot should and shouldn’t do, we reduce noise, avoid anti-patterns, and promote consistency across the codebase.

Proposed Solution

This project is a .NET 8 Web API using

• ASP.NET Core
• EF Core with SQLite
• Docker Compose
• A layered architecture with Controllers, Services, Repositories, DTOs, Validators, and AutoMapper

Tooling and conventions

• Uses CSharpier for formatting (opinionated and accepted)
• Nullable reference types are enabled
• Async programming is enforced
• Tests are written with xUnit and Moq

We want Copilot to

• Follow RESTful practices
• Use dependency injection
• Prefer EF Core async APIs with LINQ
• Generate idiomatic C# with .NET 8 features

We want to avoid

• Synchronous EF Core usage
• Static classes for services
• Raw SQL unless explicitly required
• XML comments or doc stubs

Suggested Approach

• Add a new file at .github/copilot-instructions.md

Content should include

• A brief project overview
• Coding conventions and folder structure
• Copilot dos and don’ts
• Testing tools and practices
• General philosophy for clarity and maintainability

See this initial content suggestion for reference:

# GitHub Copilot Instructions

These instructions guide GitHub Copilot on how to assist meaningfully within this repository.

## ✅ Project Overview

This project is a proof-of-concept Web API built using:
- **.NET 8 (LTS)**
- **ASP.NET Core**
- **EF Core** with a **SQLite** database for simplicity
- **Docker Compose** for basic containerization

## ✅ Coding Conventions

Follow standard C# conventions:
- Use `PascalCase` for class names, methods, and public properties
- Use `camelCase` for local variables and private fields
- Use `async/await` consistently for asynchronous code
- Prefer `var` for local variable declarations where the type is obvious
- Nullable reference types are **enabled**
- Use `CSharpier` formatting standards (opinionated)

## ✅ Architectural Patterns

This project follows a **layered architecture** with the following structure:
- **Controllers** for handling HTTP requests
- **Services** for business logic
- **Repositories** for database access
- **Models** and **DTOs** (e.g., `PlayerRequestModel`, `PlayerResponseModel`)
- **Validators** using FluentValidation
- **AutoMapper** for model conversions
- **EF Core** for database interaction

Use **dependency injection** for all services and repositories. Avoid static classes unless truly necessary (e.g., utilities).

## ✅ Copilot Should Focus On

- Generating idiomatic ASP.NET Core controller actions
- Writing EF Core queries using LINQ
- Following async programming practices
- Producing unit tests using **xUnit**
- Suggesting dependency-injected services
- Adhering to RESTful naming and HTTP status codes
- Using `ILogger<T>` for logging
- Working with Docker-friendly patterns

## 🚫 Copilot Should Avoid

- Generating raw SQL unless explicitly required
- Using EF Core synchronous APIs (e.g., `FirstOrDefault` over `FirstOrDefaultAsync`)
- Suggesting static service or repository classes
- Including XML comments or doc stubs unless requested
- Suggesting patterns that conflict with DI (e.g., `new Service()` instead of constructor injection)

## 🧪 Testing

- Use **xUnit**
- Use **Moq** for mocking
- Prefer testing **service logic** and **controller behavior**
- Place unit tests under `test/` following structure already present (e.g., `Unit/PlayerServiceTests.cs`)

## 🔧 Tooling & Environment

- Format code with **CSharpier**
- SQLite is used in development; **PostgreSQL** may be introduced in production later
- Code runs in a **Docker Compose** environment
- .NET 8 SDK is required
- All configurations live in `appsettings.*.json` files

## 🧩 Folder Conventions

- `Controllers` for Web API endpoints
- `Services` for business logic
- `Repositories` for data access
- `Models` for domain and DTO objects
- `Mappings` for AutoMapper profiles
- `Validators` for FluentValidation rules
- `Utilities` for shared helper logic

## 🧘 General Philosophy

Keep things **simple, clear, and idiomatic**. This is a learning-focused PoC — clarity and maintainability win over overengineering.

Acceptance Criteria

• File .github/copilot-instructions.md exists
• Instructions reflect current state of the project (tech stack, practices, tooling)
• Includes explicit Copilot guidance (do's and don'ts)
• Easy to update later as the project evolves
• Reviewed and approved before merge