Reject JWKs with conflicting use and key_ops

[harrshita123]

While working with JWK imports, I noticed that keys with conflicting use and key_ops values were being accepted. For example, a JWK with use: "enc" and key_ops: ["sign"] could be imported successfully, even though those two fields clearly do not match.

Chromium already rejects this kind of input using its VerifyUsages logic, but webcrypto.dart didn’t have an equivalent check. I reproduced the issue locally and confirmed the behavior.

This change adds a small, centralized validation step during JWK parsing to ensure use and key_ops are consistent. Since the check lives in one place, it automatically applies to all JWK imports without duplicating logic across different algorithms.

The intent is simply to reject invalid JWKs and bring the behavior in line with Chromium, without changing any existing cryptographic behavior.

Fixes: #58

[harrshita123]

Validation of use and key_ops alignment with modern WebCrypto behavior

As part of migrating away from the older BoringSSL version, I verified how modern browsers handle conflicts between use, key_ops, and the requested key usages by testing directly in Chrome using the public WebCrypto API.

Modern Chrome (which reflects newer BoringSSL behavior) strictly enforces alignment between:

the JWK use field

the JWK key_ops field

the key_usages passed to importKey

If these are inconsistent, Chrome correctly throws a DataError.

For example, the following JWK declares use: "sig" (signing), but the import request asks for encryption usages:

const jwk = {
kty: "oct",
k: "AAAAAAAAAAAAAAAAAAAAAA",
alg: "A128GCM",
use: "sig",
key_ops: ["encrypt", "decrypt"],
ext: true
};

await crypto.subtle.importKey(
"jwk",
jwk,
{ name: "AES-GCM" },
false,
["encrypt", "decrypt"]
);

Chrome rejects this with:

DataError: The JWK "use" member was inconsistent with that specified by the Web Crypto call.

This confirms that modern implementations require the JWK’s declared intent (use and key_ops) to be consistent with the requested key usages.

Older BoringSSL behavior was more permissive and could accept inconsistent combinations, which diverged from the WebCrypto specification and from current browser behavior.

The stricter validation introduced here ensures that webcrypto.dart aligns with modern WebCrypto semantics and behaves consistently with current browser implementations.