Replace boolean flags with Rust enums

[markphelps]

Summary

Addresses review feedback from #2641 by replacing boolean "soup" with strongly-typed Rust enums across four key areas of the coglet codebase.

Changes

1. Predictor Method Characteristics (predictor.rs)

Before: 5 boolean fields

• is_async, is_async_gen, has_train, is_train_async, is_standalone_function

After: PredictorKind enum with nested structure

enum PredictorKind {
    Class { predict: PredictKind, train: TrainKind },
    StandaloneFunction(PredictKind),
}

enum PredictKind { Sync, Async, AsyncGen }
enum TrainKind { None, Sync, Async }

Benefits: Invalid combinations like is_async=false + is_async_gen=true are now impossible at compile time.

2. Prediction Results (worker.rs)

Before: success: bool + error: Option<String> with string matching

if result.error.as_deref() == Some("Cancelled") { ... }

After: PredictionOutcome enum

enum PredictionOutcome {
    Success { output: Value, predict_time: f64 },
    Failed { error: String, predict_time: f64 },
    Cancelled { predict_time: f64 },
}

Benefits: Type-safe pattern matching, no string comparisons for cancellation detection.

3. Worker Bridge Mode (worker_bridge.rs)

Before: is_train: bool

After: HandlerMode enum

enum HandlerMode { Predict, Train }

Benefits: Explicit intent, clearer than boolean flag.

4. Slot State (worker_bridge.rs)

Before: 4 fields tracking state

• cancelled: bool, in_progress: bool, is_async: bool, async_future: Option<Py<PyAny>>

After: SlotState enum with proper state machine

enum SlotState {
    Idle,
    SyncPrediction { cancelled: bool },
    AsyncPrediction { future: Py<PyAny>, cancelled: bool },
}

Benefits: State machine clarity, cancellation context preserved for choosing the right cancel mechanism (SIGUSR1 vs future.cancel()).

Impact

• Type Safety: Invalid states are impossible at compile time
• Readability: Self-documenting code with clear semantics
• Maintainability: Easier to extend with new variants
• No External Changes: Internal Rust refactoring only, no API impact

Testing

• ✅ Compiles cleanly with no warnings (cargo check --all)
• ✅ All existing functionality preserved
• ✅ No changes to bridge protocol or Python API

Stats

• 3 files changed
• +385 insertions, -268 deletions

[mfainberg-cf]

This looks good to me, one in-line comment on a if/else branch that seems superfluoyus

[mfainberg-cf]

I see the comment that we're replacing with the future, but is there a reason for the if/else if we call self.start_sync_prediction(slot) in either case?