Security: sanitize 5xx error responses, log details server-side

[rupertgermann]

Parent

#6

What to build

Error responses can currently leak internal details to clients (audit finding M4). Make the shared route-protection wrapper the single place that maps thrown errors to client responses: when a wrapped handler throws, the client receives only the route's configured generic error message and status, while the full error (message, stack) is logged server-side. No raw upstream error text, file path, or stack fragment reaches the response body from any protected route.

Acceptance criteria

• A handler that throws an arbitrary Error produces a response whose body contains only the route's configured generic message — never the thrown message or stack
• The full error detail is logged server-side (observable via the existing request-log records or server logging)
• Intentional, typed client errors (validation failures, 4xx with safe messages) still pass through unchanged
• TDD: behavior covered at the route-protection seam (wrapper invoked directly with a throwing handler and a constructed Request); npm test green

Blocked by

None - can start immediately