fix: surface real server error details to client console

[MrDirkelz]

The API's exception filter stripped 5xx errors down to a generic message before the client ever saw them, so the app/cms console.error calls had nothing useful to log. Send the real exception.message (never .stack) to clients in all environments; the friendly toast copy is now purely a client-side display choice, unrelated to what the server sends.

[ivanslabbert]

Review summary — ✅ Approve

• Ticket fulfilled: AllExceptionsFilter now returns the real exception.message for 5xx/unknown errors instead of the generic string (api/src/exceptions/allExceptions.filter.ts:55,64), and both clients now console.error it (app/src/main.ts:136, cms/src/main.ts:108). The message already flows client-side via shared/src/api/http.ts:40, so no shared change needed.
• Correct end-to-end: actualMessage = exception instanceof Error ? exception.message : String(exception) handles Error, HttpException, and non-Error throws; spec updates cover all three. 4xx passthrough untouched.
• Sound security tradeoff: only .message is sent, never .stack (documented in the filter JSDoc allExceptions.filter.ts:14-18). Residual risk that a raw Error(...) message contains internals is explicitly accepted.
• Good placement: console.error sits before the serverErrorTimeout debounce guard, so every error is logged while toast/Sentry stay debounced; the error.message ? ... guard handles undefined safely.
• No cross-package contract impact: response shape {statusCode, message} unchanged; no DTO/sync-query/FTS/auth surface touched.

_{🤖 AI-assisted review summary (Claude Code). Read-only analysis of the PR diff — not a substitute for human review.}

[ivanslabbert]

• Sound security tradeoff: only .message is sent, never .stack (documented in the filter JSDoc allExceptions.filter.ts:14-18). Residual risk that a raw Error(...) message contains internals is explicitly accepted.

Think we need to ensure that raw error messages are not sent to the client - only extracted string messages.

[johan-bell]

Passing through the real message for all HttpExceptions regardless of status (not just <500) removes the filter's safety net for 5xx errors. Today every HttpException in the codebase uses a hardcoded 4xx string, so this isn't exploitable yet, but nothing stops a future 5xx throw like new InternalServerErrorException(dbErr.message) from leaking internals straight to the client — this filter would now consider that message "ours" and forward it verbatim. Given storageStatus.controller.ts already has a similar pattern (interpolating error.message into a response), this seems likely to happen again. Worth keeping 5xx responses generic regardless of exception type, or restricting the passthrough to an explicit allowlist of exception classes known to carry only safe, hardcoded text.