The Registry64 and Registry32 views need to be queried separately to properly detect the architecture of installed bundles. The previous change incorrectly assumed all bundles were 32-bit, but x64 and x86 runtimes are registered in different registry views.

Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

…commands

The Filterer classes (ArgFilterer and NoArgFilterer) were hardcoded to only handle 4 bundle types (Sdk, Runtime, AspNetRuntime, HostingBundle), which caused WindowsDesktopRuntime bundles to be excluded from filtering. Added WindowsDesktopRuntimeVersion filtering to both filterer methods so that Windows Desktop Runtimes are properly included in dry-run and remove command results.

Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

This reverts commit 2ca0051. Marc correctly pointed out that all .NET installers are 32-bit executables that write to the 32-bit registry view, regardless of whether they install x86 or x64 components. The architecture detection is done through display names and cache paths, not registry views.

Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>

…regex

The BundleCachePathRegex doesn't include Windows Desktop Runtime patterns, so when it tries to extract architecture from the cache path, it returns an empty string (not null). Changed the null-coalescing operator to use string.IsNullOrEmpty() check instead, so it falls back to checking the display name when the regex doesn't match. This properly detects x86/x64 from display names like "Microsoft Windows Desktop Runtime - 3.1.32 (x86)".

Co-authored-by: marcpopMSFT <12663534+marcpopMSFT@users.noreply.github.com>