Consolidate run and work order state definitions into single source of truth

[stuartc]

User story

As a developer working on Lightning, I want run and work order states to be defined in one place with well-named groupings, so I don't have to guess or hardcode state lists across the codebase.

Details

Lightning.Run and Lightning.WorkOrder each define their states via Ecto.Enum, and Run exposes final_states/0 and failure_states/0. However, several other meaningful groupings exist but have no canonical name or function — they're reconstructed inline across the codebase:

• [:available, :claimed, :started] appears in dashboard_stats.ex, runs/query.ex, and janitor_test.exs — these are the "in-progress" or "active" run states (the complement of final states)
• [:pending, :running] appears in dashboard_stats.ex and dashboard_components.ex — the active/in-progress work order states
• search_params.ex maintains its own @statuses string list that mirrors WorkOrder.states()

Each duplication is a place where adding or renaming a state requires a manual update that the compiler won't catch.

Implementation notes

• Define named groupings on Run and WorkOrder (e.g. something like active_states/0 for the non-final states) — the right names should emerge from how they're actually used
• Replace inline lists across lib/ and test/ with the new functions
• search_params.ex should derive @statuses from WorkOrder.states/0
• Frontend TypeScript mirrors (types/history.ts, useRunRetry.ts, fixture data) are necessarily separate but could be consolidated within the JS layer
• Migrations and SQL ordering constructs should be left as-is

Release notes

Internal refactor — no user-facing changes.

User acceptance criteria

• No hardcoded run or work order state lists remain in lib/ outside of the schema modules themselves
• Each meaningful state grouping has a named public function on the relevant schema module
• All existing tests pass without modification to assertions