fix(ui): use name instead of id in workflow execution triggered-by alert CEL filter

[ahbeigi]

Based on the suggestion in #6237, this PR was repurposed from the original frontend fix to instead add a defensive DataError handler at the /alerts/query API layer.

The root cause is that the Prometheus provider stores alertname as the alert id instead of a UUID (tracked in #6219). The workflow scheduler embeds this non-UUID string into triggered_by, the frontend builds a CEL filter id=="<alertname>", and the backend maps id to lastalert.alert_id (a UUID column). PostgreSQL rejects the query with invalid input syntax for type uuid — this DataError was not caught, so FastAPI returned a 500.

PR #6219 fixes this at the provider level. This PR adds a complementary safety net at the API layer so any provider storing a non-UUID alert id returns a 400 with a clear message instead of an unhandled 500, regardless of whether #6219 has been merged.

Closes #6237

📑 Description

• keep/api/routes/alerts.py: add except DataError in query_alerts alongside the existing except CelToSqlException, returning 400 instead of 500

✅ Checks

• My pull request adheres to the code style of this project
• My code requires changes to the documentation
• I have updated the documentation as required
• All the tests have passed

ℹ Additional Information

Before: any CEL query containing a non-UUID value against a UUID-typed column causes an unhandled DataError → 500 An internal server error occurred. URL: /alerts/query.

After: the same query returns 400 Invalid value in query - a field may contain a non-UUID value with the offending CEL expression in the response detail.

No breaking changes. No new dependencies. Related: #6219.

---

Note

Low Risk
Low risk: small, localized error-handling change that only alters the HTTP response for previously-unhandled database type errors (500 -> 400) when running alert queries.

Overview
Prevents /alerts/query from returning an unhandled 500 when a CEL filter supplies an invalid value for a UUID-typed field.

query_alerts now catches SQLAlchemy DataError and returns a 400 with a clearer message (including the offending CEL expression), alongside the existing CelToSqlException handling.

^{Reviewed by Cursor Bugbot for commit dd88610. Bugbot is set up for automated code reviews on this repo. Configure here.}

[CLAassistant]

All committers have signed the CLA.