Simplify SignCheck conditionals

[JeremyKuhne]

Clarify workload signing verification and fix WorkloadInfoHelper bug

Refactor the workload signing verification pipeline for clarity and
correctness. The two independent verification systems (NuGet package
signatures and MSI Authenticode) were easy to confuse due to ambiguous
naming, inconsistent defaults, and duplicated NuGetPackageDownloader
construction across call sites.

Bug fix:

• WorkloadInfoHelper passed !SignCheck.IsDotNetSigned() as the default
  for MSI verification — inverted logic that verified when the host was
  unsigned and skipped when signed. Fixed to use
  WorkloadUtilities.ShouldVerifySignatures(). (No real exposure as this is only an informational command, there is no execution / installation.)

Behavioral change:

• WorkloadManifestUpdater.GetInstance() previously called
  SignCheck.IsDotNetSigned() directly for NuGet verification, bypassing
  the registry policy check. Now calls parameterless
  ShouldVerifySignatures(), which additionally respects the
  VerifySignatures registry policy. MSI verification remains intentionally
  disabled (only downloads advertising manifests, not MSIs).

Refactoring:

• Add WorkloadUtilities.ShouldVerifySignatures() parameterless overload
  for non-interactive code paths that don't have a --skip-sign-check flag.
• Add NuGetPackageDownloader.CreateForWorkloads() factory method to
  centralize the common construction pattern (FirstPartyVerifier, source
  mapping enabled, null logger). Replaces 6 inline constructor calls.
• Rename VerifyPackage() to ValidateMsiDatabase() in
  NetSdkMsiInstallerClient to distinguish MSI database structure
  validation from cryptographic signature verification.
• Rename verifySignatures parameter to verifyMsiSignature in
  InstallerBase, WorkloadInstallerFactory, MsiInstallerBase,
  NetSdkMsiInstallerClient, and WorkloadInfoHelper to clarify that the
  parameter controls MSI Authenticode verification only.
• Log a diagnostic message when NuGetPackageDownloader's platform gate
  downgrades a verification request (e.g., on macOS without the env var).
• Delete SignCheck_Unix.cs stub — unnecessary since
  ShouldVerifySignatures() returns false at compile time on non-Windows
  before any SignCheck method is called.

Documentation:

• Add SIGNING-VERIFICATION.md in the Workload directory covering the
  policy decision flow, platform support rationale, MSI Authenticode
  layer, and entry point map.
• Add NUGET-SIGNATURE-VERIFICATION.md in the NuGetPackageDownloader
  directory covering the platform gate, TRP certificate bundles,
  verification modes (strict first-party vs. relaxed), and the
  NuGetSignatureVerificationEnabler distinction.
• Add XML documentation throughout SignCheck_Windows, WorkloadUtilities,
  NuGetPackageDownloader, FirstPartyNuGetPackageSigningVerifier, and
  MsiPackageCache.

Tests:

• Add WorkloadUtilitiesTests (3 tests) for ShouldVerifySignatures
  overloads.
• Add NuGetPackageDownloaderFactoryTests (4 tests) for CreateForWorkloads
  and the platform downgrade logging behavior.

[Copilot]

Pull request overview

This PR aims to simplify workload signature-check logic now that TARGET_ defines exist, making it explicit that signature checking is Windows-only.

Changes:

• Simplifies SignCheck_Windows by removing runtime OS checks and #if TARGET_WINDOWS blocks, assuming Windows-only compilation.
• Deletes the Unix SignCheck stub implementation.
• Removes the now-unnecessary csproj rule that excluded the Unix SignCheck file on Windows builds.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
src/Cli/dotnet/dotnet.csproj	Removes the conditional compile exclusion for the Unix SignCheck file.
src/Cli/dotnet/Commands/Workload/SignCheck_Windows.cs	Makes SignCheck strictly Windows-assumptive (no OS branching / conditional compilation).
src/Cli/dotnet/Commands/Workload/SignCheck_Unix.cs	Removes the non-Windows SignCheck stub.

[JeremyKuhne]

@baronfel, @joeloff We should consider just removing the workload signing checks for informational commands. It doesn't really matter when we aren't repairing/installing and is expensive.