refactor(errors): harden responses.error/getMessage contract and prevent internal error leakage

[PierreBrisorgueil]

Context

The current error helpers (responses.error and errors.getMessage) are widely used across controllers.

During a review, we found API-contract and security weaknesses:

• responses.error includes error: JSON.stringify(error) in client responses.
• code is overloaded between HTTP status and domain error code.
• status fallback may rely on non-numeric error.code.
• errors.getMessage can fall back to raw JSON serialization of unknown errors.

Problem

This behavior can leak internal implementation details (stack traces, DB driver errors, internal objects) and makes error handling less predictable for API consumers.

Expected behavior

• Client responses must not expose raw internal error objects.
• Error payload shape must be stable and explicit.
• HTTP status and domain error code must be separated.
• Unknown errors should return a safe generic message.

Proposed direction

1. Harden responses.error payload contract.
2. Remove or gate raw serialized error output from public responses.
3. Keep a stable status (number) and code (domain string) model.
4. Update errors.getMessage fallback to a safe generic message (no raw JSON dump).
5. Add tests for helper behavior (AppError, validation error, unknown error).

Acceptance criteria

• No raw JSON.stringify(error) in production API responses.
• Error responses keep backward-compatible keys when possible (type, message, description) while making status/code semantics explicit.
• All unknown/internal errors return a sanitized client message.
• Unit tests cover responses.error and errors.getMessage edge cases.