fix(frontend): standardize API error handling and replace inline error components with togle's

📌 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.