Standardize Execution API error responses to RFC 9457

[23tae]

This PR standardizes the Airflow Execution API error responses to follow the RFC 9457 (Problem Details for HTTP APIs) specification.

Description

Exceptions in the Execution API are caught at the FastAPI route boundary in task_instances.py and re-raised as standard HTTPExceptions. Airflow's core API framework then automatically formats these into RFC 9457 compliant JSON.

Error Response Examples

This PR demonstrates two key improvements in error handling:

Case 1: Upgrading plain string messages to structured objects

Before:

{
  "detail": "Database error occurred"
}

After:

{
  "detail": {
    "type": "about:blank",
    "title": "Internal Server Error",
    "detail": "Database error occurred"
  }
}

Case 2: Standardizing dictionaries while retaining custom context

Before:

{
  "detail": {
    "reason": "running_elsewhere",
    "message": "TI is already running elsewhere",
    "current_hostname": "worker-1",
    "current_pid": 12345
  }
}

After:

{
  "detail": {
    "type": "about:blank",
    "title": "Conflict",
    "detail": "TI is already running elsewhere",
    "reason": "running_elsewhere",
    "current_hostname": "worker-1",
    "current_pid": 12345
  }
}

Verification Results

I have verified the changes using prek and breeze.

• Static Checks (Prek): Passed
• Unit Tests (Breeze): Passed

---

closes: #62107

---

Was generative AI tooling used to co-author this PR?

• Yes

Generated-by: Antigravity following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[ashb]

Status is moot in the response body -- that's already included in the HTTP response and shouldn't be duplicated.

[23tae]

Status is moot in the response body -- that's already included in the HTTP response and shouldn't be duplicated.

@ashb Thanks for the feedback! You're right—since the status code is already in the HTTP response, having it in the body is redundant.

I've removed the status field from the error responses and updated the tests accordingly.

Before:

{
  "detail": {
    "type": "about:blank",
    "title": "Internal Server Error",
    "status": 500,
    "detail": "Database error occurred"
  }
}

After:

{
  "detail": {
    "type": "about:blank",
    "title": "Internal Server Error",
    "detail": "Database error occurred"
  }
}