patina_dxe_core: Add DxeDispatch service for driver dispatch

[kat-perez]

Description

Add a DxeDispatch service trait in the SDK and a CoreDxeDispatch
implementation in patina_dxe_core that delegates to the PI dispatcher.
The service is registered alongside other core services (MemoryManager,
PerfTimer, etc.) and consumed via dependency injection by components
that need to trigger driver dispatch passes.

• Impacts functionality?
• Impacts security?
• Breaking change?
• Includes tests?
• Includes documentation?

How This Was Tested

• Built SBSA DXE core binary with BootDispatcher + SimpleBootManager consuming the service via DI
• Booted Windows ARM64 under QEMU SBSA-ref with Patina BDS handling the full boot flow
• Connect-dispatch interleaving discovered AHCI device, expanded partial device path, loaded Windows bootloader, ExitBootServices completed
• 106 on-system unit tests passed (0 fails)

Integration Instructions

The DxeDispatch service is registered automatically by the DXE core.
Components consume it via dependency injection:

fn entry_point(self, dxe_dispatch: Service<dyn DxeDispatch>) -> Result<()> {
    dxe_dispatch.dispatch()?;
    Ok(())
}

[patina-automation]

ℹ️ QEMU Validation Skipped - PR Merged

The Patina QEMU PR validation workflow did not run because the PR was merged before validation started.

Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/23510554819

Note: Previous results are available in this comment's edit history.

This comment was automatically generated by the Patina QEMU PR Validation Post workflow.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[kat-perez]

@os-d @Javagedes this is ready for another review. thanks!

[os-d]

I think the overall approach is reasonable, we would want the other dispatch services also defined at some point, but I think it is okay to defer those until a use case arises

[kat-perez]

@os-d @Javagedes does this new implementation work better?

[makubacki]

I think this looks reasonable for making the equivalent of the DXE Services dispatch interface available to components.

There is the small probability that developers get confused and think only a component dispatch loop exists and they are responsible for using this service to start PI dispatch. Maybe a clarifying comment for that would be nice to add.

[kat-perez]

@makubacki added this in the inline docs:

/// Note: The DXE core already runs a PI dispatch loop automatically. This
/// service is only needed when a component must explicitly trigger a dispatch
/// pass at a specific point in its execution.
pub trait DxeDispatch {
...