Refactor: Move driver-specific preparation logic out of generic runDriverEntry dispatcher

[crazygo]

Issue Description

The runDriverEntry function in ui.tsx currently contains special-cased logic specifically for the Story driver (lines 991-1015). This creates tight coupling between the generic dispatcher and a specific driver implementation, which undermines the modularity and extensibility of the driver pattern.

Problem

The generic dispatcher now has hardcoded knowledge of the Story driver, which creates several issues:

1. Tight Coupling: Generic dispatcher knows about specific driver implementation
2. Scalability Issues: More drivers = more special cases in dispatcher
3. Maintainability: Driver changes require modifying core dispatcher
4. Extensibility: New drivers can't add preparation logic without touching dispatcher

Proposed Solution

Add an optional prepare function to DriverManifestEntry interface that allows each driver to define its own preparation logic. The generic runDriverEntry would then call this function if it exists, keeping the dispatcher agnostic of specific driver needs.

Benefits

• Loose coupling between dispatcher and drivers
• Better scalability and extensibility
• Cleaner separation of concerns
• Easier to add new drivers with custom preparation

Priority

Medium - Architectural improvement that doesn't block current functionality. Should be addressed when working on driver-related features.

Labels

architecture, refactoring, drivers, modularity