Validate patina_boot against an adversarial Secure Boot matrix

Parent: #190

Goal

Prove how boot-source policy interacts with platform image authentication under hostile or misconfigured conditions.

Matrix

• Secure Boot enabled/disabled
• SetupMode and deployed mode
• unsigned and revoked images
• unintended but validly signed EFI applications
• internal storage, removable USB, synthesized fallback, and duplicate partitions
• injected event, protocol, allocation, and image-load failures

Acceptance criteria

• expected allow/deny outcome is defined for every matrix row
• hardware or QEMU evidence is attached for every supported row
• failure paths are deterministic and fail closed where security state is incomplete
• OEM policy requirements are documented separately from guarantees delegated to UEFI LoadImage
  "@},
  @{Title='Build a UEFI BDS semantic parity matrix for patina_boot'; Stream=2f52b344; Body=@"
  Parent: #190

Goal

Make supported behavior and intentional policy differences explicit relative to EDK2 BdsDxe/UefiBootManagerLib.

Coverage

• BootOrder, BootNext, BootCurrent, active/inactive and duplicate options
• OptionalData and maximum-size variables
• Driver, SysPrep, Boot, and PlatformRecovery option categories
• EndOfDxe, ReadyToBoot, Before/AfterConsole, and platform event ordering
• watchdog, console, OS indications, deferred images, and failure behavior

Acceptance criteria

• matrix labels each behavior supported, platform-policy, intentionally unsupported, or planned
• every supported row links to a host, QEMU, or hardware test
• upstream API documentation defines compatibility expectations
• OEMs can identify migration gaps without reading implementation source

Start with patina_boot and parent issue #190, then compare the Secure Boot and UEFI behavior requested here with EDK2 BdsDxe/UefiBootManagerLib and the UEFI LoadImage expectations. Build the specified matrices and run supported rows on QEMU or hardware. Done means every row has an allow/deny or compatibility label, evidence, deterministic failure behavior, and separately documented OEM requirements.