[Bug]: XPC Communication Race Conditions

### I have done the following

- [x] I have searched the existing issues
- [ ] If possible, I've reproduced the issue using the 'main' branch of this project

### Steps to reproduce

It complex asynchronous patterns with locks and task coordination that could lead to race conditions.

### Current behavior

Asynchronous Message Handling
- XPC messages are processed asynchronously
- Multiple handlers can be active simultaneously for different requests
- No clear synchronization between related operations

Shared Resource Access
- Multiple XPC requests can access shared resources (containers, networks, etc.)
- Lock usage is inconsistent across the codebase
- Some operations appear to assume sequential execution

Callback Management
- Completion handlers are used throughout the XPC communication
- There's potential for callbacks to be invoked in unexpected order
- Some callbacks may never be called if a race condition occurs

State Transition Issues
- Container state transitions may not be properly synchronized
- Operations could be attempted on containers in incompatible states
- Race between status checks and operations

### Expected Behavior

**Synchronization**
Atomic State Transitions
- Container state changes should be atomic operations
- State transitions should use appropriate locking mechanisms
- State should be consistent across all components

Access Control
- Shared resources should have clear ownership models
- Consistent lock acquisition order to prevent deadlocks
- Fine-grained locking to avoid unnecessary contention

Thread-Safe Message Handling
- XPC message handlers should be thread-safe
- Concurrent requests should not interfere with each other
- Service implementations should handle overlapping requests correctly

**Error Handling**
Consistent Error Propagation
- Errors should be properly propagated through the XPC hierarchy
- Failure states should be clearly communicated to clients
- Timeouts should be implemented for all operations

Graceful Recovery
- The system should recover from communication failures
- Resources should be properly released even when operations fail
- Failed operations should leave the system in a consistent state

**Callback Execution**
Callback Invocation
- Each callback should be invoked exactly once
- Callbacks should occur even if the connection is terminated
- Proper timeout and cancellation handling

**Ordered Execution**
- Operations with dependencies should be executed in the correct order
- Results should be delivered in a predictable sequence
- Long-running operations shouldn't block critical path operations

### Environment

```markdown
- OS: macOS 26 Beta 1
- swift: Apple Swift version 6.2
- xcode: Xcode 26 Beta 17A5241e
- container: container CLI version 0.1.0
```

### Relevant log output

```shell
[2025-06-12 14:32:15.234] [container-apiserver] [INFO] Received request to start container ID: abc123
[2025-06-12 14:32:15.235] [container-runtime-linux] [DEBUG] Processing start request for container abc123
[2025-06-12 14:32:15.236] [container-apiserver] [INFO] Received state request for container ID: abc123
[2025-06-12 14:32:15.237] [container-runtime-linux] [ERROR] Container state request while transition in progress
[2025-06-12 14:32:15.240] [container-runtime-linux] [DEBUG] Container abc123 state changed to: starting
[2025-06-12 14:32:15.242] [container-apiserver] [WARN] Concurrent operations detected on container abc123
[2025-06-12 14:32:15.245] [container-runtime-linux] [ERROR] Failed to complete container startup: resource lock timeout
[2025-06-12 14:32:15.250] [container-apiserver] [ERROR] XPC message response timeout: start_container
```

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct