Feature/85/implement global error handler middleware

[skorpionreser]

JIRA

• Implement Global Error Handler Middleware

Code reviewers

• @Mult1pers
• @emil720a1
• @M1R4MI
• @Exlizardium
• @Loki22978964
• @Laminate32

Second Level Review

• @DrFaust555

Summary of issue

The API did not have centralized handling for unhandled exceptions. This could result in inconsistent error responses, duplicated exception-handling logic, and potential exposure of internal implementation details.

A global exception-handling mechanism was required to log unexpected errors and return a consistent, secure response to API clients.

Summary of change

• Implemented GlobalExceptionHandler using the .NET 10 IExceptionHandler interface.
• Registered the handler through AddExceptionHandler<GlobalExceptionHandler>().
• Registered the standard IProblemDetailsService through AddProblemDetails().
• Added the built-in exception-handling middleware to the request pipeline.
• Added structured logging with the HTTP method, request path, and trace identifier.
• Added standardized 500 Internal Server Error responses using ProblemDetails.
• Added traceId to error responses for correlation with server logs.
• Prevented exception messages and stack traces from being exposed to clients.
• Added unit tests covering successful and unsuccessful Problem Details response writing.

CHECK LIST

• СI passed
• Сode coverage >=95%
• PR is reviewed manually again (to make sure you have 100% ready code)
• All reviewers agreed to merge the PR
• I've checked new feature as logged in and logged out user if needed
• PR meets all conventions

closes #85

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarQube Cloud

[emil720a1]

Before approval, please address the following issues:

1. This branch is behind the latest dev. dev already registers AddProblemDetails(), ValidationExceptionHandler, and UseExceptionHandler(). Please rebase or merge the latest dev, remove the duplicate ProblemDetails/middleware registrations, and register GlobalExceptionHandler after ValidationExceptionHandler. The order is important: validation exceptions must remain 400 responses, while only unhandled exceptions should reach the global 500 handler.

2. GlobalExceptionHandler currently returns false when IProblemDetailsService cannot write the response. Returning false tells ExceptionHandlerMiddleware that the exception was not handled. Please follow the existing ValidationExceptionHandler approach: write ProblemDetails using WriteAsJsonAsync as a fallback and return true. The current test expecting false should be replaced with a fallback-response test.

3. Please add middleware-level integration coverage for the interaction between ValidationExceptionHandler and GlobalExceptionHandler: validation exceptions should remain 400, while an unhandled exception should produce a 500 application/problem+json response containing a traceId and no sensitive exception message.

Also, please add the missing newline at the end of the two newly added files.