Require InclusiveNamespaces to be in the exc-c14n namespace when verifying #633

Problem

Both places that read an InclusiveNamespaces element match it by local name in any namespace. utils.findChildren takes an optional namespace, and neither call passes one:

• loadReference, for a reference's Transform (src/signed-xml.ts#L784-L787)
• exclusive C14N's lookup under SignedInfo's CanonicalizationMethod (src/exclusive-canonicalization.ts#L268-L273)

The spec defines one element in one namespace, http://www.w3.org/2001/10/xml-exc-c14n#, for both xml-exc-c14n# and xml-exc-c14n#WithComments (Exc-C14N §4):

<schema targetNamespace="http://www.w3.org/2001/10/xml-exc-c14n#" ...>
  <element name="InclusiveNamespaces" type="ec:InclusiveNamespaces"/>

An element with that local name in any other namespace isn't the exclusive C14N parameter, but the library applies its PrefixList as if it were. .NET's SignedXml rejects such a signature with "Unknown transform".

The lenient match keeps old signatures verifying. xml-crypto 6.3.2 and earlier wrote a reference's InclusiveNamespaces in a namespace named after each Transform's Algorithm, which for xml-exc-c14n#WithComments is http://www.w3.org/2001/10/xml-exc-c14n#WithComments. #632 fixes the signer and keeps the reader lenient, pinned by inclusive_namespaces_in_with_comments_namespace.xml.

The element is inside SignedInfo, so only the signer can produce it. This is a conformance problem, not a bypass.

Proposal

Pass the exc-c14n namespace at both lookups, and reject a Transform or CanonicalizationMethod whose InclusiveNamespaces is in any other namespace, with an error that names it. Ignoring the element instead would still fail verification, but as an unexplained digest mismatch.

This stops signatures from xml-crypto 6.3.2 and earlier that use xml-exc-c14n#WithComments with a prefix list from verifying, so it belongs in 7.0.