Canofy Process Standardization & Refactoring

User Story
As a Canofy user, I want the application to validate my inputs and handle failed or unavailable ULIP services gracefully, so that incorrect searches or API failures do not cause the application to break and I receive clear feedback about what went wrong.

Description
Implement input validation, error handling and failure-management mechanisms across the ULIP verification modules.
The application should validate user-provided search values before submitting requests, handle unsuccessful API responses, and gracefully manage simulated server/API failures.
The implementation should provide clear and user-friendly error messages while preventing invalid requests or unexpected service failures from breaking the application workflow.
The current implementation uses predefined mock failure and server-error scenarios in the ULIP client to test these behaviours before integration with the actual ULIP APIs.

Configuration / Prerequisites
Verification modules and search workflows implemented.
Input fields and search types configured.
ULIP client/service layer available.
Mock failure scenarios configured.
Mock server-error scenario available using:
ERROR500
Mock "not found" scenarios configured for relevant services.
Frontend error banners/messages and backend exception handling implemented.

Acceptance Criteria
Required search fields cannot be submitted when empty.
Invalid or incomplete input is rejected before an API request is made where applicable.
Search type and search value are validated according to the selected verification service.
Failed API responses are handled without breaking the application.
"No record found" responses are displayed as clear user-facing messages.
API/server exceptions are caught and converted into appropriate error responses.
Users receive a clear indication when the external ULIP service is unavailable.
Loading/freeze states prevent duplicate submissions while a request is being processed.
Errors allow the user to return to the search screen and retry the request.
Validation and API failures do not result in application crashes or unusable pages.
The error-handling structure can accommodate the actual ULIP API response/error formats once government API access is provided.

Test Cases
TC01 – Empty Search
Attempt to proceed without entering a search value.
Expected: Application prevents submission and displays a message such as "Please enter a value."

TC02 – Invalid Search
Enter an invalid/non-existent reference such as:
000-00000000
Expected: The request completes without crashing and displays the appropriate No record found message.

TC03 – Vehicle Not Found
For Vehicle Verification, enter:
MH12AB9999
Expected: Verification fails gracefully and displays "Vehicle not found."

TC04 – API/Server Failure
Enter:
ERROR500
Expected: The simulated ULIP service throws an exception, which is handled gracefully and displayed to the user as a service/API failure rather than exposing a Python error or breaking the page.

TC05 – Retry After Failure
Trigger an API failure and return to the search screen.
Expected: User can modify the search value and perform another verification successfully without refreshing the entire application.

TC06 – Duplicate Submission
Click the Verify/Next button multiple times while the API request is processing.
Expected: The application prevents duplicate requests through the loading/freeze state and processes only the intended verification request.