Draft: fix: improve API error handling

📌 Description:

This MR improves the way API errors (such as 422 and 500) are handled and displayed in the application. Previously, errors were shown as raw objects, generic network errors, or unclear messages, making it difficult for volunteers to understand what went wrong.

The error handling logic has now been enhanced to extract meaningful messages from API responses and display them in a clear, user-friendly format using the centralized alert/toggle system.

🐞 Problem:

• 422 (Validation Errors) were displayed as raw response objects.
• 500 (Internal Server Errors) were shown as generic "Network Error" or unclear messages.
• Volunteers could not easily understand what action was required to resolve the issue.

✅ Changes Implemented

• Enhanced 422 Error Handling
• Display clear, readable validation messages.
• Improved 500 Error Handling
• Extract meaningful messages from server responses.

🎯 Result:

• Volunteers now see clear and understandable error messages.
• No raw JSON objects or technical error details are displayed.
• Consistent and professional error handling across the application.
• Improved usability and reduced confusion during patient-related workflows.

🧪 Tested Scenarios:

• Invalid form submissions (422 validation errors)
• Backend internal server errors (500)
• Missing or malformed request data
• Network-related failures