Migrate patina_boot to Patina UEFI Services

[kat-perez]

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 patina_boot: Benchmark execute end to end #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 [major] Add Initial Patina UEFI Services [Rebase & FF] patina#1743

Dependencies

• Blocked by [major] Add Initial Patina UEFI Services [Rebase & FF] patina#1743
• Blocks the final form of Microbench BootOrchestrator::execute() end-to-end (mocked) #124 and the upstream RFC re-proposal in Prepare the patina_boot upstream RFC re-proposal #200
• Coordinates with Implement the upstream patina_boot semantic baseline #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 Build a UEFI BDS semantic parity matrix for patina_boot #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.

[kat-perez]

Scheduling decision: defer implementation until OpenDevicePartnership/patina#1743 has stabilized or merged. This is an upstream-readiness gate, not current-iteration work. Continue requirements mapping and isolate new code from StandardBootServices where practical, but do not begin the full service-model migration yet.