Fix Windows PowerShell private dependency loading

[PrzemyslawKlys]

Summary

• preload Desktop dependencies in metadata-derived dependency order before importing exported binary modules
• scope Windows PowerShell AssemblyResolve handling to the module's private Lib tree, with a bounded bootstrap window for CLR requests that omit the requesting assembly
• unregister the resolver on module removal and on terminal import failures
• keep PowerShell Core on the existing isolated AssemblyLoadContext path

Why this matters

Windows PowerShell 5.1 can request a compatible private dependency without identifying the requesting assembly while a netstandard dependency graph is loading. A global resolver is unsafe, while refusing every ownerless request prevents otherwise valid packaged modules from importing. This change supports only the short preload/import phase, validates canonical candidate paths, and then returns to requester-owned resolution.

Validation

• ModuleBootstrapperGeneratorTests: 23/23 on net10.0
• PowerForge, PowerForge.PowerShell, and PSPublishModule: Release/net472 builds with zero warnings and errors
• PSPublishModule self-build imported from the installed artifact in PowerShell 7 and Windows PowerShell 5.1
• the resulting installed builder packaged ComputerX and TestimoX; both packages imported in PowerShell 7 and Windows PowerShell 5.1