Clarify SignatureMatches consumption contract: content-digest check, not signature verification (docs + ContentDigestMatches alias)

Summary

CoseSign1MessageIndirectSignatureExtensions.SignatureMatches(...) checks whether a supplied artifact's
digest equals the digest embedded in the indirect signature's COSE_Sign1 .Content. It is a
content-digest comparison, not a signature verification step — but the method name and its XML docs
read as though it validates "the signature." That is a consumer-clarity / documentation gap: a developer
can reasonably misread SignatureMatches as "the signature is valid," when verifying the COSE_Sign1
signature (and establishing signer trust) is a separate step the caller is expected to perform.

This issue is about closing that documentation / API-naming gap so the intended consumption pattern is
obvious. It is not a defect in the shipping validation path: CoseHandler.Validate(...) already verifies the
signature first and only then compares the indirect content digest.

Where the confusion comes from

SignatureMatches(artifact)
└─ SignatureMatchesInternal
   ├─ CoseHashEnvelope → IndirectSignatureFactory.HashMatches(hashAlg, .Content, artifact)
   ├─ CoseHashV        → CoseHashV.Deserialize(.Content).ContentMatches(artifact)
   └─ Direct           → SequenceEqual(.Content, Hash(artifact))

All three paths recompute the artifact digest and compare it to the digest stored in .Content. None verify
the COSE_Sign1 signature — by design; that is the caller's responsibility. The naming overloads the word
"signature" (the cryptographic COSE_Sign1 signature vs. the indirect signature artifact), which is the root
of the confusion.

Intended consumption pattern

• For end-to-end validation, consumers should use CoseHandler.Validate(...), which verifies the signature +
  trust and then compares the indirect content digest.
• Consumers calling the extension directly are expected to verify the COSE_Sign1 signature and establish signer
  trust first (for example VerifyEmbedded/VerifyDetached together with a trust decision), then call the
  matcher purely to compare the content digest.

Proposed documentation / clarity improvements

1. Update the XML docs on SignatureMatches(...) (and the class) to state plainly that it performs a
   content-digest comparison only and that the caller is expected to verify the signature/trust first. Correct
   the "matches the signature of the artifact" wording.
2. Add an intent-revealing alias ContentDigestMatches(...) (same Stream / Byte[] shapes) that redirects
   to SignatureMatches(...), so new code reads clearly and the overloaded "Signature" term is avoided.
3. Update docs/CoseIndirectSignature.md with the consumption contract and a corrected example.

Notes

• The newer V2 and native validation pipelines already express this pattern structurally (indirect content
  matching runs as a post-signature step), so this issue is scoped to the V1 surface and its documentation.

Affected (V1) surface

• CoseIndirectSignature/Extensions/CoseSign1MessageIndirectSignatureExtensions.cs
• CoseIndirectSignature/Extensions/CoseSign1MessageCoseHashVExtensions.cs
• CoseIndirectSignature/Extensions/CoseSign1MessageCoseHashEnvelopeExtensions.cs
• docs/CoseIndirectSignature.md

Start with CoseIndirectSignature/Extensions/CoseSign1MessageIndirectSignatureExtensions.cs and its SignatureMatches XML docs, then review the related CoseHashV and CoseHashEnvelope extension files. Use docs/CoseIndirectSignature.md to align the consumption contract and example. Done means the docs clearly distinguish digest comparison from signature verification and the ContentDigestMatches alias covers the stated Stream and Byte[] shapes.