Fix/agent execution diagram fixes

[meghana21-arch]

Pull Request type

• Bugfix
• Feature
• Refactoring (no functional changes, no api changes)
• Build related changes
• WHOSUSING.md
• Other (please describe):

Changes in this PR

Sorting by Agent Name / Workflow Name was unreliable — clicking ascending or descending returned the same row order. The sort handler remapped the column's workflowType id to workflowName, a field no backend (sqlite/postgres/ES) indexes, so the sort param was silently dropped. Fixed in Agent Executions, Workflow Executions, and Task Search (same bug was copy-pasted into all three).

Before / After

Issue #1514

Alternatives considered

Keeping workflowName as the wire format and adding it as an accepted field alias in each persistence backend's query builder (sqlite, Postgres, ES) instead of fixing the UI. Rejected — more surface area to keep in sync across four backends versus a one-line fix at the single place the wrong name originates.

[manan164]

Confirmed this is the right fix — workflowName isn't a field on any backend: it's absent from VALID_FIELDS in both the sqlite and postgres query builders, and absent from the ES6/7/8 mappings, where workflowType is the keyword field with doc_values: true.

Worth noting the failure mode differs by backend, which may explain the "unreliable" framing in #1514. On sqlite/postgres the sort field is dropped silently and rows come back in query-plan order. On Elasticsearch the unmapped field is rejected outright — verified against a live ES-backed server:

sort=workflowName:ASC  -> HTTP 500  (search_phase_execution_exception, all shards failed)
sort=workflowType:ASC  -> HTTP 200  (correctly ordered)

So on ES deployments the page fails to load entirely rather than mis-ordering.

I opened #1518 with tests-only coverage pinning that contract in both query builders, to complement this PR — no overlap with your changes.