Fix the type of exception thrown when decoding bad headers

[bartonjs]

CoseMessage's Decode routines say that any failure is a CryptographicException, but some of the validation failures leak out ArgumentException from the validation in CoseHeaderMap.

[dotnet-policy-service]

Tagging subscribers to this area: @bartonjs, @vcsjones, @dotnet/area-system-security
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR fixes a bug where CoseMessage.DecodeSign1 and CoseMessage.DecodeMultiSign methods would leak ArgumentException from internal validation in CoseHeaderMap, breaking the documented contract that decode failures should throw CryptographicException. The fix wraps these exceptions and also adds support for indefinite-length CBOR arrays in critical headers validation.

Changes:

• Modified exception handling in DecodeBucket to wrap validation ArgumentException into CryptographicException
• Refactored CBOR array/map parsing to support both definite and indefinite-length encoding
• Added comprehensive test coverage for critical header validation with both encoding styles

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/libraries/System.Security.Cryptography.Cose/src/System/Security/Cryptography/Cose/CoseMessage.cs	Added exception wrapping in DecodeBucket and refactored to support indefinite-length CBOR collections
src/libraries/System.Security.Cryptography.Cose/tests/CoseMessageTests.DecodeSign1.cs	Added tests verifying CryptographicException is thrown for critical header validation errors
src/libraries/System.Security.Cryptography.Cose/tests/CoseMessageTests.DecodeMultiSign.cs	Added tests verifying CryptographicException is thrown for critical header validation errors in multi-sign messages
src/libraries/System.Security.Cryptography.Cose/tests/CoseMessageTests.Sign.CustomHeaderMaps.cs	Extended existing tests to cover both definite and indefinite-length critical header arrays