Standardize API error responses to a single error field

[benhegartysefe]

Background

Follow-up from PR #751 review (thread: #751 (comment)).

Different API endpoints currently return error information in different shapes — a bare JSON string (BadRequest("…")), a DTO with a Message property (e.g. CopyEnvBuildResponseDto), serialized exception objects (StatusCode(500, exception)), and ASP.NET ProblemDetails (title/detail). To cope, the client ApiCaller.ExtractErrorMessage (src/Dorc.Core/ApiCaller.cs) has to probe several candidate fields, which is fragile and easy to get wrong.

Goal

Standardize on a single error contract returned by every API endpoint, so clients read one field.

Proposed scope

1. Define one error-response shape (e.g. { "error": "…" }, or ASP.NET ProblemDetails with a single agreed field) and document it.
2. Update controllers to return that shape consistently for 4xx/5xx, and stop returning raw exception objects / stack traces to clients (use a correlation id; log details server-side). This overlaps with a separate security concern about verbose error/stack-trace disclosure across the API (DefaultExceptionHandler and several controllers returning StatusCode(500, e) / error + " - " + ex).
3. Simplify ApiCaller.ExtractErrorMessage to read the single field once the server side is consistent.
4. Add/adjust tests.

Notes

• Cross-cutting change touching most controllers — intentionally kept out of PR Code-review & security-audit fixes: error handling, build-URI parsing, authorization, LDAP & encryption hardening (with tests) #751 to keep that PR scoped.
• Once done, the multi-field probing added in Code-review & security-audit fixes: error handling, build-URI parsing, authorization, LDAP & encryption hardening (with tests) #751 can be removed.