fix (code-signing): Disable code-signing of nuget package's contents - causes identity problems for "dotnet run"

[turbobobbytraykov]

Description

With the --recurse-containers false flag, the step applies only the NuGet author signature to the package itself (.signature.p7s) and leaves the container contents untouched. Nothing of value is lost:

• DLLs are still Authenticode-signed — the dedicated "Sign DLLs" step (+ "Validate DLL signatures" gate) runs before dotnet pack, so the package embeds already-signed assemblies. The container pass was merely re-signing them redundantly.
• The package is still author-signed and timestamped — dotnet nuget verify continues to pass.
• JS static web assets enter the package pristine, matching the manifest hashes.

This also generalizes: any of our ASP.NET Core / Blazor packages that ship static web assets (JS/CSS with SRI hashes in Microsoft.AspNetCore.StaticWebAssets.props) has the same hazard, and --recurse-containers false is the same one-line fix, provided assemblies are signed pre-pack.

Motivation / Context

Fixes #267 — Failed to find a valid digest in the 'integrity' attribute for resource '...IgniteUI.Blazor.Lite.*.lib.module.js' ... The resource has been blocked. when consuming the published package in a .NET 10 Blazor WebAssembly app.

Referencing IgniteUI.Blazor.Lite 0.1.0 from a stock .NET 10 Blazor WebAssembly Standalone app and running dotnet run leaves the app stuck at "Loading". The browser console shows:

Failed to find a valid digest in the 'integrity' attribute for resource
'http://localhost:xxxx/_content/IgniteUI.Blazor/IgniteUI.Blazor.Lite.5g0qjy678t.lib.module.js'
with computed SHA-256 integrity 'Ezw3dvPXa+ZVVStf5TpfIu2ZK0+nZw8g14iZW05IeWE='.
The resource has been blocked.

Because the blocked file is a Blazor JS initializer (*.lib.module.js), the WASM runtime fails to start entirely (MONO_WASM: Failed to import library initializer).
By default the sign tool treats the nupkg as a container and recursively Authenticode-signs every supported file inside it — including all 8 .js static web assets (.js is a signable WSH-script type for the tool, signed by appending a // SIG // ... // SIG // End signature block comment trailer).

The failure chain:

1. dotnet pack computes SHA-256 hashes of every static web asset and freezes them as <Integrity> values in build/Microsoft.AspNetCore.StaticWebAssets.props inside the package.
2. The post-pack signing step then mutates the .js files inside the nupkg by appending the // SIG // signature block — invalidating the frozen hashes. Audit of the shipped 0.1.0 package: 27 of 81 manifest entries mismatched (every .js asset).
3. In a consuming .NET 10 app the SDK emits those stale hashes as SRI integrity attributes (via the importmap generated by OverrideHtmlAssetPlaceholders), the browser's subresource-integrity check fails, and the file is blocked.

It only manifests in dotnet run / development because dotnet publish re-fingerprints and recomputes asset integrity, masking the corruption.

Note: Authenticode signing of .js files exists for Windows Script Host scripts (AppLocker/WDAC script enforcement). It is meaningless for browser-delivered JavaScript — browsers don't verify Authenticode, and Microsoft does not Authenticode-sign dotnet.js/blazor.webassembly.js either. For static web assets the signature block is pure corruption.

Type of Change (check all that apply):

• Bug fix
• New functionality
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (no functional changes)
• Documentation
• Demos
• CI/CD
• Tests
• Changelog

Component(s) / Area(s) Affected:

N/A

How Has This Been Tested?

• Unit tests
• Manual testing
• Automated e2e tests

Test Configuration:

• .NET version:
• Hosting model:
• Browser(s):
• OS:

Screenshots / Recordings

Checklist:

• All relevant tags have been applied to this PR
• This PR includes unit tests covering all the new code
• This PR includes API docs for newly added methods/properties
• This PR includes general feature table updates in the root README.MD
• This PR includes CHANGELOG.MD updates for newly added functionality
• This PR contains breaking changes
• This PR includes behavioral changes and the feature specification has been updated with them
• Accessibility (ARIA, keyboard navigation, focus management) has been verified