feat(application): application and API building blocks (handlers, validation, error responses)

[MendesMat]

Closes #6

What

Adds the plumbing every future use case will share: the in-house command handler contract, a FluentValidation decorator that runs before it, and the translation of Result/Error failures into the Problem Details shape documented for the API.

Why

ADR-0007 (CQRS without MediatR), ADR-0008 (validate with FluentValidation) and ADR-0009 (Result pattern + Problem Details) define these building blocks; this pull request implements them. docs/api/conventions.md API-12/API-13 describe the error JSON shape, and API-14 (added here) fixes the verbatim message for an unexpected failure.

How to test

dotnet test --solution ControlService.slnx

123/123 tests pass; dotnet build ControlService.slnx -v q -clp:Summary is clean (0 warnings); dotnet format ControlService.slnx --verify-no-changes is clean.

Decisions taken along the way (the owner confirmed all of these before or during the work)

• Error → HTTP status. A small table in the API project (ErrorStatusCodes), code → status, mirroring the ADR-0009 table. A code missing from it falls back to 500 without hiding the code/message, since that is a programming mistake, not a business outcome — kept distinct from UnexpectedErrorExceptionHandler, which handles a real unhandled exception with the generic API-14 message and never exposes the exception itself.
• Field errors and details on Error. Error gained optional Fields (camelCase path → messages) and Details (free-form data, e.g. updatedByName) instead of a separate ValidationError subtype, so the API layer has one shape to translate.
• Decorator registration. By hand, no Scrutor (ADR-0007 allows either). There are no concrete handlers yet to decorate, so no generic registration helper was written — that will happen per-handler when the first real command exists.
• FluentValidation.DependencyInjectionExtensions was added to Directory.Packages.props (version matches the already-approved FluentValidation 12.1.1) as the issue asked, but no project references it yet: nothing to register.
• ICurrentUser and TimeProvider were left out of this issue. Nothing here needs them, and ICurrentUser's shape depends on the JWT claims that only exist from issue Authentication: sign-in, sessions and the Admin's first access #8 onward; they will be introduced with the audit interceptor in issue Persistence: EF Core, PostgreSQL, audit, concurrency and seeded system records #7.
• Test strategy for the Problem Details mapping. I originally planned a WebApplicationFactory integration test with a test-only endpoint injected through IStartupFilter. That endpoint never registered reliably under minimal hosting (repeated 404s I could not root-cause in the time available), so I switched to unit-testing ErrorResults.ToProblem(error, httpContext) directly against a DefaultHttpContext — same translation logic, no HTTP server. One real WebApplicationFactory test (RouteGroupTests) still confirms /api/v1 mounts without breaking the pipeline (API-01); that piece has no meaningful Red since no feature registers a route under it yet.
• A discovery during the pause for the traceId test: ASP.NET Core's own AddProblemDetails() already fills the traceId extension by default (Activity.Current?.Id), so my own explicit line was dead duplication — removed in the Refactor step.

Checklist

• Developed test-first: every behavior has a test that failed before the code existed (ADR-0033) — two cycles (test 6 and test 10) had no Red because the general rule was already covered by an earlier cycle; documented at each pause and verified by temporarily breaking the code to confirm the test would catch a regression.
• dotnet test --solution ControlService.slnx passes locally (123/123)
• Documentation updated: docs/api/conventions.md (API-14 and the error codes table)
• Rule IDs covered: API-01, API-12, API-13, API-14, ADR-0007, ADR-0008, ADR-0009, ADR-0028
• User-facing message (API-14) is the text the owner confirmed in conversation