Code Quality: Implement specific error handling for jAI search API endpoint

Nobody has claimed this yet.

## **Problem**
The jAI search API endpoint (`src/pages/api/jai/search.js`) currently uses a generic error handler that returns basic error information for all failures. This makes it difficult for users and developers to understand the cause of errors and respond appropriately.

## **Current Behavior**
- All errors are caught and returned as a generic error message with status 500 (or e.status if present).
- No distinction between validation errors, network errors, rate limiting, or other specific scenarios.

## **Expected Behavior**
- The API should distinguish between different error types and return specific, user-friendly messages and appropriate HTTP status codes.
- Should handle:
- Validation errors (400)
- Network/service errors (503)
- Rate limiting (429)
- Generic server errors (500)

## **Location**
File: `src/pages/api/jai/search.js`

## **Proposed Implementation**
```javascript
catch (e) {
console.error('jAI Search API Error:', e);
// Handle different types of errors
if (e.name === 'ValidationError') {
return Response.json(
{ error: 'Invalid request parameters', details: e.message },
{ status: 400, headers: corsHeaders }
);
}
if (e.name === 'NetworkError' || e.code === 'ENOTFOUND') {
return Response.json(
{ error: 'External service unavailable', details: 'AI service is temporarily unavailable' },
{ status: 503, headers: corsHeaders }
);
}
if (e.status === 429) {
return Response.json(
{ error: 'Rate limit exceeded', details: 'Too many requests. Please try again later.' },
{ status: 429, headers: corsHeaders }
);
}
// Generic server error
return Response.json(
{ error: 'Internal server error', details: process.env.NODE_ENV === 'development' ? e.message : 'Something went wrong' },
{ status: e.status ?? 500, headers: corsHeaders }
);
}
```

## **Steps to Complete**
1. Update catch block to handle specific error types.
2. Return 400 for validation errors, 503 for network/service errors, 429 for rate limiting, 500 for generic errors.
3. Test each error scenario.

## **Definition of Done**
- [ ] Error handler distinguishes between error types.
- [ ] Each error returns a specific status code and message.
- [ ] CORS headers are included in all error responses.
- [ ] Existing functionality for successful requests remains intact.

Start by reading src/pages/api/jai/search.js, focusing on the existing catch block and how successful responses use CORS headers. Exercise validation, network, rate-limit, and generic failure paths, then verify each returns the specified status, message, and CORS headers without changing successful requests.

Written by the indexing model from the issue text.