Kernel scheduling-history conditions reference the pre-rename from_phase/to_phase columns

KernelSchedulingHistoryConditions.by_from_phase / by_to_phase reference KernelSchedulingHistoryRow.from_phase and .to_phase. Those columns exist under different names: the kernel_scheduling_history table defines from_status and to_status. Both factories return a lazily-evaluated closure, so either raises AttributeError once its condition is evaluated.

## How the names drifted

An incomplete rename. BA-3061 created kernel_scheduling_history with from_phase/to_phase columns. BA-3062 renamed them to from_status/to_status by editing that not-yet-released migration in place, but the query conditions added in the same change kept the old names. The stale reference then survived the move from repositories/scheduling_history/options.py into models/scheduling_history/conditions.py (BA-5127).

It stayed hidden because nothing calls either factory yet, so the closure is never evaluated, and because a cast() wrapper keeps the bad attribute access away from the type checker.

## Impact

No user-visible impact today: the fault is unreachable because the factories have no callers. BA-6882 is the first code to call them, so it would surface the fault.

## Acceptance Criteria

- Conditions target the real from_status / to_status columns
- Named consistently with the equivalent SessionSchedulingHistoryConditions factories
- The cast() masking the attribute error is removed
- pants test passes for affected packages

JIRA Issue: BA-6887

Start in models/scheduling_history/conditions.py and compare KernelSchedulingHistoryConditions with the equivalent SessionSchedulingHistoryConditions factories. Verify the row columns and inspect the lazy closures and cast() usage, then run the affected packages with pants test. Done means both conditions use from_status/to_status consistently, the masking cast is gone, and the tests pass.

Written by the indexing model from the issue text.