[PowerDisplay] Confirm before enabling module; log EdidId in Phase 0

[moooyo]

Summary of the Pull Request

Two crash-correlation aids for the kernel-side DDC/CI BSOD mitigated by #47734:

1. Log EDID hardware ID (manufacturer + product code, e.g. DELD1A8) during Phase 0 monitor classification, before any DDC/CI capability fetch enters the BSOD risk window.
2. Show a confirmation dialog before turning the Power Display module on from the Settings page, so the user understands the BSOD risk before the first capability fetch runs.

PR Checklist

• Closes: #xxx
• Communication: I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected
• Tests: Added/updated and all pass
• Localization: All end-user-facing strings can be localized
• Dev docs: Added/updated
• New binaries: Added on the required places
  • JSON for signing for new binaries
  • WXS for installer for new binaries and localization folder
  • YML for CI pipeline for new test projects
  • YML for signed pipeline
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

1. Phase 0 EdidId logging

MonitorIdentity.EdidIdFromDevicePath parses the EDID hardware ID segment from a DevicePath of the form \?\DISPLAY#DELD1A8#5&abc&0&UID12345#{guid} and returns DELD1A8. The 3-letter PNP manufacturer code + 4-hex product code is identical for every physical unit of the same model, so it identifies the model without leaking per-unit identifiers.

MonitorManager logs the EdidId on the existing Phase 0 classification line. Phase 0 uses QueryDisplayConfig, which reads OS-cached EDID and cannot BSOD, so this line is guaranteed on disk before the crash-prone Phase 2 capability fetch starts. If a machine crashes during enumeration, the recovered log identifies every attached model (including same-model duplicates), which makes it possible to correlate crash reports to specific monitor models even when the user can't tell us which monitor caused the crash.

2. Enable-module confirmation dialog

PowerDisplayViewModel.IsEnabled setter is refactored to follow the same two-phase pattern already used by MaxCompatibilityMode:

• false → true does not commit immediately; it kicks off ConfirmAndEnableModuleAsync, which awaits the existing DangerousFeatureWarningDialog (resource prefix PowerDisplay_EnableModule) and either commits or reverts the ToggleSwitch via OnPropertyChanged.
• true → false commits unconditionally — we never block a user who wants to turn the module off.
• App-startup loads via InitializeEnabledValue() / RefreshEnabledState() assign the _isEnabled field directly, bypassing the setter, so the dialog never fires on settings restore or GPO refresh.
• GPO-configured state still short-circuits before any dialog logic.

The dialog reuses the existing DangerousFeatureWarningDialog injected by PowerDisplayPage.xaml.cs. The 5 new PowerDisplay_EnableModule_* strings explain that the BSOD is in Windows (not Power Display), that Power Display will auto-disable itself after a detected crash, and that the user has to re-enable + dismiss the warning each time.

Validation Steps Performed

• Built src/settings-ui and src/modules/powerdisplay locally.
• Unit tests: added EdidIdFromDevicePath_* cases to MonitorIdentityTests, all green.
• Settings UI manual: toggling Power Display ON now shows the warning dialog. Pressing Cancel reverts the ToggleSwitch visually; pressing Enable commits and the module starts. Toggling OFF does not prompt. Restarting Settings UI with PowerDisplay enabled does not prompt. GPO-disabled state still locks the toggle.
• Log inspection: MonitorManager Phase 0 log now shows EdidId=... for each path before any capability fetch.

🤖 Generated with Claude Code