ErrorCatalog as the Single Source of Truth and Dual-Channel Error Handling

Context

Error codes/messages/HTTP statuses scattered inside controllers caused drift; the application-side and protocol-side error body formats are inherently different.

Decision

For every error code (including OAuth2 protocol codes), the code/numeric/category/HTTP status/default message treats the compile-time ErrorCatalog as the sole authority; Application endpoints use the ErrorResponder error envelope, while protocol endpoints use the RFC 6749 error body (including the Filter layer); the frontend error catalog mirrors the backend's and is validated at build time (errorAdapter is a pure function). Principle: distinct failure causes must not be folded into the same code; exception: anti-enumeration scenarios (account lockout sharing the same code as a wrong password) are deliberate design.

Consequences and Current State

ErrorCatalog.cc (525 lines) + unit tests force documentation sync (the api-reference error table is verified by tests); the 4006 added in PR#85 went through exactly this process.