fix: Differentiate between setup and processing errors

[AjitPadhi-Microsoft]

Purpose

Improved error handling in the /api/input_task endpoint by distinguishing between failures during service initialization and errors that occur during task processing.

Previously, any exception was caught and returned as a 400 Bad Request. This was misleading, as a failure to initialize the kernel or agents is a server-side issue (5xx), not a client-side one (4xx).

The logic is now wrapped in separate try...except blocks. Failures during the setup phase will correctly return a 500 Internal Server Error, providing a more accurate and actionable error response for both the client and for system monitoring.

• Solves Bug: Fixes a bug where server-side initialization failures in the /api/input_task endpoint were incorrectly reported to the client as a 400 Bad Request.
• Improves Correctness: Aligns the API with HTTP standards by returning a 500 Internal Server Error for server-side exceptions, providing clearer and more accurate error feedback.
• Enhances Debugging: Makes the system easier to debug for both client-side developers and operators by clearly distinguishing between a faulty client request (4xx) and a server failure (5xx).
• Increases Robustness: Adds a finally block to ensure external client connections are closed, preventing potential resource leaks during an error state.

Does this introduce a breaking change?

• Yes
• No

How to Test

1. Test the success case:

   • Run the backend server with valid environment variable configurations.
   • Send a valid POST request to the /api/input_task endpoint.
   • Expected: Receive a 200 OK response with the plan details.

2.  **Test the server-error case:**

      * Stop the server.
      * Temporarily invalidate a required environment variable for service initialization (e.g., set `AZURE_SEARCH_ENDPOINT` to an invalid URL).
      * Restart the server.
      * Send the same valid POST request to `/api/input_task`.
      * **Expected:** Receive an `HTTP 500 Internal Server Error` with the detail: `"Could not initialize services for your request."`. This confirms the fix.

What to Check

Verify that the following are valid

• A standard, successful request to /api/input_task functions correctly and returns a 200 status.
• When a service initialization fails due to a bad configuration, the endpoint correctly returns a 500 status code, not 400.
• The error message for the 500 error is clear and does not expose internal implementation details.
• Errors that occur later in the process (e.g., a malformed plan or a rate-limiting error) still result in the appropriate 4xx status code.

Other Information

This change is a foundational fix for API stability and correctness. It ensures the service behaves predictably and follows established web standards for error reporting.