## ADDED Requirements

### Requirement: Driver type registry lives in the driver layer
The system SHALL provide a registry, owned by the `driver` package, that maps a `driver_type` string (e.g. `"wda"`) to a builder function producing a `DriverFactory` for that type, so that any caller needing to construct a driver for a device does so without importing a concrete driver class directly.

#### Scenario: Building a factory for a known driver type
- **WHEN** a caller requests a driver factory for `driver_type="wda"` with connection info (e.g. `server_url`, `udid`)
- **THEN** the registry returns a `DriverFactory` that, when invoked, constructs a working `WDADriver` configured with that connection info

#### Scenario: Building a factory for an unknown driver type
- **WHEN** a caller requests a driver factory for a `driver_type` that is not registered
- **THEN** the registry raises a clear error naming the unsupported `driver_type`, instead of returning `None` or a factory that fails later at connect time

### Requirement: Adding a driver type requires no changes outside the driver layer
The system SHALL allow a new driver type to be added by registering it in the `driver` package's registry alone; no other package (`api/`, `device/`, `tools/`, `runtime/`) SHALL need code changes to support constructing devices of the new type.

#### Scenario: API layer is agnostic to registered driver types
- **WHEN** the console config API resolves a `driver_type` string into a driver factory to register a device
- **THEN** it does so by calling into the driver registry rather than maintaining its own mapping of `driver_type` to concrete driver classes