Refactor provider composition and ESLint configuration

- Add new provider composition system with validation
- Create providerComposition.tsx for centralized provider management
- Implement providerOrderValidator.tsx to ensure correct provider order
- Add comprehensive tests for provider composition
- Create custom ESLint rules in frontend/eslint-rules/
- Update ESLint configuration
- Update architecture and tasks documentation

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

Docs/Tasks.md

@@ -1,52 +1,3 @@
-## [IMPORTANT] Error response schema inconsistent
-
-**Where found**
-
-- Different handlers return different response shapes
-- Fail2Ban errors: `{ "error_code": "...", "detail": "..." }`
-- Validation errors: `{ "detail": [...] }`
-- Not found errors: `{ "detail": "...", "error_code": "..." }`
-
-**Why this is needed**
-
-Frontend must normalize multiple shapes, making error handling fragile and error-prone.
-
-**Goal**
-
-Unify all error responses to single schema.
-
-**What to do**
-
-1. Define canonical error response:
-   ```python
-   class ErrorResponse(BaseModel):
-       error_code: str
-       message: str
-       status: int
-       details: dict | None = None
-   ```
-
-2. Update all handlers to return this format
-3. Update frontend to expect unified schema
-
-**Possible traps and issues**
-
-- Backward compatibility with old clients
-- FastAPI's built-in handlers may override custom
-- Rich detail structures need accommodation
-
-**Docs changes needed**
-
-- Update API documentation with unified error schema
-- Add error code reference table
-
-**Doc references**
-
-- `Docs/API.md` (error codes)
-- `backend/app/main.py` (exception handlers)
-
----
-
 ## [IMPORTANT] Provider ordering fragility (Frontend)
 
 **Where found**