API responses use a consistent error format

When API routes return { error: string } in some places, { message: string } in others, and { success: false, reason: string } elsewhere, frontend error handling code must branch on shape — and branches that aren't tested get skipped. CWE-755 (Improper Handling of Exceptional Conditions) applies when inconsistency leads to unhandled error shapes in client code. ISO 25010 maintainability.consistency classifies format divergence as a direct maintainability defect. Practically, inconsistent formats cause error messages to silently go undisplayed: a client written against { error } silently ignores a response shaped as { message }, and users see no error feedback at all.

Create a single error response helper in src/lib/api-response.ts and use it in every route's catch block.

// src/lib/api-response.ts
export function errorResponse(message: string, status: number = 500) {
  return NextResponse.json({ error: message }, { status })
}

export function validationErrorResponse(errors: Record<string, string>) {
  return NextResponse.json({ error: 'Validation failed', fields: errors }, { status: 422 })
}

Standard status codes to apply: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 422 Unprocessable Entity, 429 Too Many Requests, 500 Internal Server Error. Audit existing routes for any that return 200 for error conditions — these must be corrected to 4xx or 5xx.