Potential fix for code scanning alert no. 3: Information exposure through a stack trace

[fwartner]

Potential fix for https://github.com/fwartner/clawd-office/security/code-scanning/3

To fix the issue, error responses should no longer include raw exception text derived from e. Instead, the server should return a generic error message (for example, "Invalid request body" or "Internal server error") while logging the detailed error (including stack trace) on the server. This avoids leaking stack traces or internal error messages to clients while maintaining debuggability.

The most localized and non‑disruptive change is to update each catch (e) { json(res, 400, { error: String(e) }) } block to:

• Log the error to the server console, preferably including e.stack when available.
• Return a generic error JSON payload that does not contain e or e.stack.

Because different routes correspond to different classes of errors, we can slightly tailor the generic messages without relying on the actual exception text. For example:

• Where the error is likely due to client input (e.g., parsing JSON or validating a PATCH body), respond with "Invalid request" or "Invalid request body".
• Where it might be an internal failure, respond with "Internal error".

Concretely, in server.mjs:

• Leave json() unchanged; it is a generic helper and is not inherently unsafe.
• Modify each catch (e) at lines 382, 411, 448, 509, 576, 608, and 638 (and any similar ones in the omitted sections, if present) to:
  • Call console.error('Descriptive context...', e) to log details.
  • Replace String(e) with a fixed, non‑sensitive message, e.g., { error: 'Invalid request body' } or { error: 'Internal server error' }.

No new methods or external libraries are necessary; we can rely on Node’s built‑in console.error. This single pattern change removes the flow of stack‑trace‑derived data to JSON.stringify(data) while preserving existing API structure and status codes.

Suggested fixes powered by Copilot Autofix. Review carefully before merging.