UI: prefer active state over queued when colouring collapsed groups

[nathadfield]

Collapsed task groups and mapped tasks in the graph and grid views took their badge / border / icon colour from the backend's agg_state(), which ranks queued/scheduled ahead of running/deferred. A group with one queued task and five running tasks rendered queued-coloured even though most of its children were actively executing. The segmented state bar from #61854 already showed the proportional mix correctly, but the surrounding visual elements stayed on agg_state.

This PR adds a frontend getDisplayState helper that ranks active/error states ahead of pending states, and routes the dominant colour through it across the five rendering surfaces that consume an aggregate state: the graph node (TaskNode.tsx), grid cell (GridTI.tsx), shared tooltip "State:" line, group/mapped detail-page headers, and the graph MiniMap. The helper returns null for no-status dominants so callers keep their existing no-status placeholder rather than leaking the serialized "None" key into Chakra tokens.

The graph state filter (useGraphFilteredNodes.ts) is also realigned, but to a "matches any child state" predicate rather than the dominant rendering — an operator filtering for "running" expects to find running work even when it's buried inside a fail-dominant group. Leaf tasks still match by single state.

Two pre-existing rendering bugs for the "None" key in the segmented-bar slice and tooltip per-state breakdown are tracked at #67541 with in-code pointers at each affected site.

related: #67541

---

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

• Yes

Generated-by: Claude Code (Opus 4.7) following the guidelines

[bbovenzi]

We should update the order inSTATE_PRIORITY in parameters.py