Sokovan Scheduler Refactoring

## Overview

Refactor the monolithic `scheduler.py` (38 methods with mixed responsibilities) into a well-structured, maintainable architecture following the Coordinator pattern established in the deployment component.

## Goals

- **Separation of Concerns**: Extract scheduling logic into Provisioner, Launcher, and Cleaner engines
- **Coordinator Pattern**: Implement middleware approach for history tracking and metrics collection
- **Data Structure Consolidation**: Use existing `SessionInfo`/`KernelInfo` types instead of flat dataclasses
- **Consistent Result Types**: Apply deployment pattern with `SchedulerExecutionResult` (successes, errors, skipped)

## Target Architecture

```
scheduler/
├── scheduler.py # Composition layer (simplified)
├── coordinator.py # Router + middleware (history, metrics, state transitions)
├── types.py # Consolidated types
├── provisioner/ # PENDING → SCHEDULED
│ ├── handler.py
│ ├── allocators/
│ ├── selectors/
│ ├── sequencers/
│ └── validators/
├── launcher/ # SCHEDULED → RUNNING (prepare + start)
│ └── handler.py
└── cleaner/ # TERMINATING → TERMINATED (terminate + sweep)
└── handler.py
```

## Sprint Plan

- Sprint 0: Data Structure Consolidation
- Sprint 1: Coordinator + Handler Structure
- Sprint 2: Provisioner Extraction
- Sprint 3: Launcher Extraction
- Sprint 4: Cleaner Extraction
- Sprint 5: Integration and Legacy Cleanup

JIRA Issue: BA-3119