Bug: run_module doesn't cleanup service when start_service fails

[richardkiene]

Bug Description

When run_module API endpoint creates a service but start_service() fails, the service is left in creating state without cleanup. This leaves orphaned services that:

• Cannot be started (invalid state transition)
• Cannot be stopped (invalid state transition from 'creating' to 'stopping')
• May not be deletable (daemon hangs on delete request)

Root Cause

In fabricksd/src/api/handlers/services.rs lines 282-287:

match manager.create_service(config).await {
    Ok(id) => {
        // Start the service
        if let Err(e) = manager.start_service(&id).await {
            return Json(error_response(&e));  // <- Service left in 'creating' state!
        }
        ...
    }
    ...
}

When start_service fails, the code returns an error but doesn't delete the already-created service.

Expected Behavior

If start_service() fails, the service should be cleaned up (deleted) before returning the error.

Proposed Fix

match manager.create_service(config).await {
    Ok(id) => {
        // Start the service
        if let Err(e) = manager.start_service(&id).await {
            // Cleanup: delete the service that failed to start
            let _ = manager.delete_service(&id).await;
            return Json(error_response(&e));
        }
        ...
    }
    ...
}

Reproduction

1. Create a WASM module that fails to start (e.g., invalid component)
2. Run fabricks run module:tag
3. Observe service stuck in creating state
4. fabricks service ls shows the stuck service
5. fabricks service rm <id> may hang or fail

Impact

This was discovered while implementing JavaScript runtime support (Issue #25).