Improve Template/ISO Failure Status and Error Reporting

### The required feature described as a wish

**Description:**
In the ISO/Templates flow, error responses currently return detailed error messages directly in the status field. This leads to inconsistencies and complicates error handling.

**Proposal:**
Introduce two improvements to the API responses for Templates and ISOs:

1) Standardize the `status` Field for Failures
When any terminal error occurs during the processing of a template or ISO, the `status` field should consistently return `"Failed"`. This provides a clear and unambiguous final state for parsing.

2) Add a Detailed Error Message Field
A new field, named `error_details`, should be added to the Template/ISO API response object.
This field will contain a detailed error string explaining the reason for the failure.

**Example of the response**
Failed download status of the ISO/Template:
```
{
"id": "a1b2c3d4-xxxx-yyyy-zzzz-e5f6g7h8i9j0",
"name": "my-failed-template",
"status": "Failed",
"error_details": "HTTP Server returned 404 (expected 200 OK)",
....
}
```
Successful download status of the ISO/Template:
```
{
"id": "b1b2c3d4-xxxx-yyyy-zzzz-e5f6g7h8i9j1",
"name": "my-template",
"status": "Download Complete",
"error_details": null,
....
}
```
**Benefits:**
- Consistent error structure across ISO/Templates;
- Easier parsing, logging, and UI display of error messages;
- Avoids issues caused by leading/trailing spaces or unexpected values in status.

Tasks:
1) Update ISO/Templates logic to return "Failed" in the `status` field.
2) Return detailed error messages in the `error_details` field.

Start by tracing the ISO/Templates API response handling and the terminal error paths described in the issue. Check every failure response and the successful download response, then verify that failures use "Failed" with the detailed message in error_details and successful responses use a null error_details value.

Written by the indexing model from the issue text.