[v3-2-test] UI: Return 400 instead of 500 from structure_data on malformed asset_expression (#67489)

[github-actions]

• UI: Return clear 500 detail from structure_data when asset_expression is malformed

The /structure/structure_data endpoint calls get_upstream_assets() to walk the
serialized Dag's asset_expression. If the stored expression contains an unknown
key or asset type, get_upstream_assets() raises TypeError("Unsupported type: ...").
The exception escaped uncaught and FastAPI returned a generic
{"detail": "Internal Server Error"} body with no context about which Dag
triggered it, forcing operators to dig through server logs to identify the
broken Dag.

Wrap the call in try/except TypeError and re-raise as HTTPException(500) with a
detail message identifying the Dag id and version. Still a 500 (the underlying
data corruption is genuinely server-side, not bad client input), but now with a
controlled, debuggable response body.

Regression test mocks get_upstream_assets to raise TypeError and asserts the
response is 500 with a detail message that includes the Dag id.

• Use 400 BAD_REQUEST for malformed asset_expression per review feedback

Per @jason810496 review feedback on #67489: the malformed asset_expression
ultimately originates from user-authored Dag code (via the Task SDK), so the
appropriate response is 400 BAD_REQUEST rather than 500 INTERNAL_SERVER_ERROR.

• Change status code from 500 to 400 in structure_data.
• Add HTTP_400_BAD_REQUEST to create_openapi_http_exception_doc so the OpenAPI
  spec advertises the new error response.
• Update regression test to assert 400 and rename accordingly.

Detail message is unchanged per reviewer: "It's fine to add more context".

• Revert uv.lock diff

---

(cherry picked from commit eccbdb1)

Co-authored-by: Deepak kumar deepakkumar@meta.com
Co-authored-by: pierrejeambrun pierrejbrun@gmail.com

[jason810496]

Unrelated CI failure. I will merge right away.