Refactor ban management with domain models and mappers

- Add ban domain model for core business logic separation
- Implement mapper pattern for DTO/domain conversions
- Update ban service with new domain-driven approach
- Refactor router endpoints to use new architecture
- Add comprehensive mapper tests
- Update documentation with architecture changes

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Docs/Tasks.md

@@ -1,22 +1,3 @@
-## 6) Raw DB connection exposed as dependency for all routes
-- Where found:
-	- [backend/app/dependencies.py](backend/app/dependencies.py)
-- Why this is needed:
-	- Architectural boundary relies on convention, not enforcement.
-- Goal:
-	- Enforce repository boundary for persistence access.
-- What to do:
-	- Prefer repository dependencies in routers.
-	- Restrict direct DB usage to repository/service internals.
-- Possible traps and issues:
-	- Large refactor may touch many endpoint signatures.
-- Docs changes needed:
-	- Add dependency layering rule to backend guidelines.
-- Doc references:
-	- [Docs/Backend-Development.md](Docs/Backend-Development.md)
-
----
-
 ## 7) Service layer coupled to response/presentation models
 - Where found:
 	- [backend/app/services/ban_service.py](backend/app/services/ban_service.py)