feat(registry): add GPO override warning alerts and WhatIf dry-run previews

[HetCreep]

Resolves #610

Changes

• Implemented GPO policy override warnings to alert users if enterprise Group Policies will undo registry modifications.
• Implemented a dry-run preview mode (-WhatIf) for registry modifications that safely intercepts imports and previews operations (Set Registry Value, Remove Registry Value, Remove Registry Key).

[Raphire]

Heya,

Thanks for taking the time to contribute. These 2 features seem like fine additions, although from a quick glance at the implementation they probably don't cover all features/paths.

I don't have time right now to fully dive into this PR, but I will return to this ASAP.

[HetCreep]

Thanks for the feedback!

You are completely right. Initially, the -WhatIf dry-run and GPO check focused on the registry-backed changes (loaded from .reg files). I have updated this branch to expand -WhatIf support to non-registry modifications in the script:

1. Appx Package Removal (RemoveApps.ps1): It now intercepts the removal and logs [WhatIf] Remove App Package: <app> instead of calling winget or Remove-AppxPackage.
2. Microsoft Store Suggestions (DisableStoreSearchSuggestions.ps1): It now previews the restrictive file ACL actions (or the restoration of full control) on store.db instead of performing the filesystem and ACL changes.
3. Start Menu Customization (ReplaceStartMenu.ps1): It now intercepts the folder/file creation, copy, and backup operations for start2.bin, printing a preview message instead.

Other parts like optional features (WindowsOptionalFeatures.ps1) natively support -WhatIf because they delegate to standard PowerShell cmdlets (e.g., Disable-WindowsOptionalFeature) which natively implement the dry-run parameter.

[Raphire]

Heya,

Thanks for the making the changes.

After looking at this further I think the current GPO logic has a pretty big overhead that probably isn't worth the cost. It also potentially misses many of the policies, as they don't necessarily follow a standardised structure. Instead I propose to do a boot check if the device is domain joined, and show a warning like so:

$isDomainJoined = (Get-CimInstance Win32_ComputerSystem).PartOfDomain
if ($isDomainJoined) {
    Write-Warning "This machine is domain-joined. Group Policy may override changes made by Win11Debloat."
}

Keeps it simple, and avoids many potential issues.

As for the WhatIf feature, I still see some features that are not guarded.

• DisableWidgets (Stop-Process on Widget processes runs before RemoveApps)
• ExecuteAllChanges (Creates registry backup, creates system restore point)
• Restoring backups
• Import/export config

I also don't necessarily like the need for $DryRun needing to be injected into these functions, especially because it can be confusing as in other places a check for $WhatIfPreference is used. Maybe instead check for WhatIf parameter similarly to other control variables across the script. Example:

$script:Params.ContainsKey("WhatIf")