fix(api): sanitize error responses in HTTP handlers

[skhaz]

Why

HTTP handlers wrote raw upstream error strings into client responses, disclosing driver/schema/internal error details to external clients — the same information-disclosure class as the userspace login credential leak.

What

A per-namespace api_error helper logs the raw error server-side via logger and returns only { success = false, error = <public message> }. Every HTTP handler routes its error responses through it. HTTP status codes and other response fields are preserved; text (non-JSON) handlers log the error and write a static message.

Testing

• HTTP-endpoint leak mapper (cross-references http.endpoint → handler source): zero raw error variables reach any client response field after the change. Remaining grep hits are all server-side log: tables, sanitizing helpers, or guarded client-safe domain messages.
• luac -p clean on all edited non-type-annotated files.
• Internal contract/process returns and server-side log lines were intentionally left unchanged (not client-facing).

[skhaz]

Superseded by a runtime-level egress secret-redaction filter in wippyai/runtime: a single central control that masks known secrets in all HTTP responses (and alerts on it) without per-project changes. Closing this per-project boundary sanitization in favor of that approach.