Draft: fix(frontend): standardize API error handling

📌 Summary

This MR fixes improper error message handling across the application. Previously, API errors (such as 422 and 500) were being displayed as raw objects or generic network errors instead of user-friendly messages.

The error handling mechanism has now been standardized, and all error messages are displayed properly using the global alert system.

🐞 Problem

API errors (422, 500, etc.) were displayed as:
Raw error object
Unformatted JSON
Generic “Network Error”
Some pages rendered error messages as inline components inside the UI.
Error handling logic was inconsistent across different pages (e.g., Patient Registration and others).
Poor user experience due to unclear or unreadable error messages.

✅ Changes Implemented

Standardized API Error Handling
Extracted meaningful error messages from API responses.

Properly handled:

422 Validation Errors
500 Server Errors
Network errors
Ensured fallback messages are shown when response data is unavailable.
Replaced Inline Error Components
Removed page-level error display components.
Replaced them with centralized alert/toast system.

Errors are now displayed using:

showAlertError()
showAlertSuccess()

Improved UX Consistency:

All errors now appear as alert/toast notifications.

Removed cases where errors were rendered directly inside page layout.

Alerts are consistent across:

Patient Registration

Assign Doctor Page

Other API-driven pages

Removed Local Error State

Eliminated unnecessary useState error variables.

Replaced with useAlertReplacement() hook for centralized control.

🎯 Result

Clean and user-friendly error messages.
No more raw error objects shown in UI.
Consistent alert behavior across all pages.
Better separation of concerns (no UI-level error state clutter).
Improved maintainability and scalability of error handling.