Add telemetry for boot transition failures

[kat-perez]

Problem

PR #203 made failures of the EndOfDxe / DxeSmmReadyToLock transition fail closed: an error now propagates to the non-returning BDS fatal path instead of resetting, invoking the general boot-exhaustion handler, attempting recovery, or dispatching an image. Because this happens before console discovery, production systems still need a platform-observable failure signal that does not depend on console logging.

Discussion: #203 (comment)

Already implemented in PR #203

• transition failures propagate to the non-returning BDS fatal path;
• the existing log path records a generic boot security-transition error;
• the platform does not reset, retry, invoke the general failure handler, or attempt recovery after transition failure;
• tests confirm that neither EndOfDxe nor DxeSmmReadyToLock failure reaches LoadImage().

Remaining work

Add a dedicated, platform-observable telemetry/status-code path before entering the fatal spin.

The reporting path must:

• identify whether EndOfDxe signaling or DxeSmmReadyToLock installation failed;
• include the returned EFI error/status when available;
• work in release builds and before console discovery without relying on console logging;
• be restricted to telemetry/status-code reporting and avoid device connection, image loading, or recovery dispatch;
• preserve the existing fail-closed behavior: do not invoke the general boot-exhaustion failure handler, reset the platform, or retry the transition.

Acceptance criteria

• A platform can observe both EndOfDxe and DxeSmmReadyToLock transition failures in a release build without relying on console logging.
• Tests cover reporting for each transition stage and its EFI error/status.
• Existing successful boot, fatal transition handling, and boot-option exhaustion behavior remain unchanged.