Migrate patina_boot to Patina UEFI Services

Parent roadmap: #190

Goal

Migrate patina_boot from direct StandardBootServices component dependencies to the granular Patina UEFI Services introduced by OpenDevicePartnership/patina#1743.

Why

Patina's major-branch component model removes StandardBootServices as a component parameter. Driver, event, image, protocol, timing, and TPL access are exposed as cohesive service traits with generated mockall mocks. Aligning with that model removes the need for a full raw UEFI boot-services table in host tests and makes the upstream API consistent with Patina's direction.

Scope

• replace BootOrchestrator and BootDispatcher boot-service parameters with the required Patina UEFI service dependencies
• map helper functions to driver, event, image, protocol, timing, and TPL service traits
• use generated service mocks in host tests and benchmarks
• remove the full raw boot-service mock table from PR #201
• document the temporary runtime-variable boundary until Patina provides equivalent runtime services

Acceptance criteria

• patina_boot no longer accepts StandardBootServices through its component-facing API
• host tests use generated UEFI service mocks instead of a hand-populated efi::BootServices table
• the end-to-end orchestrator benchmark runs against service mocks
• runtime-variable access is isolated behind an explicit adapter or Patina service
• the migration is based on the merged/final API from OpenDevicePartnership/patina#1743

Dependencies

• Blocked by OpenDevicePartnership/patina#1743
• Blocks the final form of #124 and the upstream RFC re-proposal in #200
• Coordinates with #199 so semantic logic remains portable across the service migration

Proposed design

BootDispatcher is the Patina adapter

The component entry point consumes the granular Patina services it needs:

• Service<dyn ProtocolServices>
• Service<dyn DriverServices>
• Service<dyn EventServices>
• Service<dyn ImageServices>
• Service<dyn TimingServices>
• Service<dyn DxeDispatch>
• image Handle

Use ProtocolServices to publish the BDS architectural protocol. Bridge the injected services into the context-free BDS callback with the ServiceCell pattern introduced by Patina #1743 rather than exposing raw UEFI tables.

Runtime variables remain behind a crate-owned BootVariableStore trait. The initial adapter may use StandardRuntimeServices; replace it when Patina provides runtime-variable services.

BootOrchestrator owns policy, not firmware APIs

Do not pass six Patina services directly into BootOrchestrator. Give it a stable crate-owned domain context instead:

pub trait BootOrchestrator: Send + Sync + 'static {
    fn execute(&self, session: PreBootSession<'_>) -> Result<!, BootError>;
}

PreBootSession composes the Patina services through internal adapters and exposes domain operations such as device discovery, console setup, boot-option enumeration, and the security transition.

Enforce the security transition with typestate

let locked = session
    .connect_and_dispatch()?
    .discover_console()?
    .enter_locked_boot()?;

locked.launch_selected_option(policy)?;

enter_locked_boot() must signal EndOfDxe and install ReadyToLock in order. It returns LockedBootSession only when both succeed. Only LockedBootSession exposes image load/start operations, making pre-lock image launch unrepresentable through the safe API.

Keep policy behind explicit traits

• BootVariableStore: BootOrder, BootNext, BootCurrent, and load-option access
• BootSourcePolicy: allowed devices, fallback behavior, and Secure Boot requirements
• BootOptionResolver: semantic handling selected from #196
• ConnectPolicy: product-specific controller connection choices

The default mechanism stays generic; Maa and OEM policy implementations live in consumer crates.

Test and benchmark layers

1. Unit-test service adapters with Patina's generated Mock*Services types.
2. Test SimpleBootManager against a mocked crate-owned boot session.
3. Benchmark the real orchestrator/domain path with service mocks; do not construct raw UEFI tables.
4. Keep one QEMU integration test for the dispatcher/service wiring and BDS callback.

This separates policy cost from Patina adapter cost and keeps API changes localized to BootDispatcher and the adapter layer.

Start with the BootDispatcher and BootOrchestrator entry points after OpenDevicePartnership/patina#1743 reaches its final API. Trace the existing service parameters, helper mappings, host mocks, benchmark, and runtime-variable boundary described in the issue. Done means the acceptance criteria pass, including service mocks, the orchestrator benchmark, an explicit runtime adapter, and the QEMU wiring test.