security: VALIDATION error handler leaks received input values in 400 response

[andrew-bierman]

Discovered during review of #2083.

File: packages/api/src/index.ts:28-33

if (code === 'VALIDATION') {
  return new Response(JSON.stringify({ error: 'Validation failed', details: error.message }), { ... });
}

Elysia's VALIDATION error.message includes the full JSON-Schema failure payload, which contains the actual received value of the failing field. A client posting a malformed JWT, password, or API key into a validated body will see those bytes echoed back in the 400 response body.

Why it matters: error trackers (Sentry), reverse proxies, and client-side logs can persist these response bodies, creating an audit-trail of secret-adjacent values.

Fix options:

1. Return only { error: 'Validation failed' } — drop details entirely
2. Return a redacted summary: { path, expected } without received

Option 1 is safer; option 2 preserves debuggability for non-sensitive fields at the cost of requiring per-field allowlisting.

Related: #2083 (introduced by the central onError handler added with the Elysia rewrite)