fix: sanitize error responses to prevent stack trace exposure

[sorlen008]

Summary

Addresses finding #2 from #218 (ASF-2026-2047): error messages were returned directly to clients without sanitization, potentially revealing internal paths, stack traces, and application structure.

Changes

• app/routes/api.chat.ts: The getErrorMessage fallback in toDataStreamResponse previously returned the raw error.message to the client. Now returns a generic "An unexpected error occurred. Please try again later." while logging the full error server-side via console.error().

• src/api/tools/commonTools.ts (searchRepositoryCode): Error catch block was interpolating the raw error object into user-facing response text (An error occurred while searching code: ${error}). Replaced with a static message; detailed error is logged server-side.

• src/api/tools/commonTools.ts (fetchUrlContent): Same pattern — raw error was embedded in the response text. Now returns a generic message.

• src/api/test-setup.ts (handleR2TestSetup): R2 upload failure results included error.message in the JSON response body. Removed the error detail from the response; it is now only logged server-side.

Approach

The fix follows a consistent pattern across all four locations:

1. Log the full error server-side (console.error) for debugging
2. Return a generic, safe message to the client

Specific known-safe error messages (rate limit, API key missing) in api.chat.ts are preserved as-is since they contain no internal details.

Testing

• npx tsc --noEmit passes with no errors
• Pre-commit hooks (lint-staged / prettier) pass

Fixes #218

Test plan

• Trigger a chat error (e.g., invalid API key) and verify the response contains a generic message, not a stack trace
• Trigger a code search failure and verify no internal error details leak
• Trigger a URL fetch error and verify sanitized response
• Verify server logs still contain the full error for debugging