test: cover ECDH deriveBits length boundaries

[harrshita123]

Follow-up to #289.

This change adds explicit ECDH deriveBits boundary coverage for each supported curve:

• exercises the exact maximum length in generated cases;
• verifies the documented maximum succeeds; and
• verifies the first invalid bit length is rejected.

The tested limits are 256 bits for P-256, 384 bits for P-384, and 528 bits for P-521.

[jonasfj]

Please rebase, I think CI mostly works on master branch now.

[harrshita123]

Please rebase, I think CI mostly works on master branch now.

I have rebased the branch onto the latest master so the CI tests can run properly.

[harrshita123]

I updated the branch based on the feedback:

• Rebased the PR onto the latest master, which resolved the merge conflict.
• Kept the ECDH deriveBits documentation change focused on the maximum length for each curve.
• Moved the new ECDH deriveBits boundary tests out of crypto_subtle_test.dart and into the package test runner under lib/src/testing/ecdh/derive_bits.dart.
• Simplified the tests to use shared curve cases for P-256, P-384, and P-521.
• Left the JSDomException behavior out of this PR since it was called out as a separate issue.

I also cleaned up the branch history into a single commit and verified it locally with dart format, dart analyze, and dart test test/webcrypto_test.dart -p vm.

[HamdaanAliQuatil]

these tests are still useful even though #130 was closed by #289. the generated cases added there don’t actually hit the documented limits: maxDeriveLength is a bit count, but those calls pass 32/48/66, and the random range excludes its upper bound.

could we correct those calls here by setting both minDeriveLength and maxDeriveLength to 256/384/528 respectively?

since #130 is already closed, I’d also reframe this as a follow-up to #289, replace Fixes #130, and perhaps rename the PR to test: cover ECDH deriveBits length boundaries.

[jonasfj]

I think these runner.generate things spit out JSON that we put into _testData.

Feel free to make a follow up PR, where we generate a bunch of these with the configurations you put in here. I've usually generated in chrome/firefox/boringssl, but just have one or two of those configurations could be useful.

Mostly those _testData entries serves as sanity tests and pins behavior.

[harrshita123]

Thanks for clarifying how runner.generate is intended to be used. I’ll keep that work separate from this PR and add a focused follow-up with generated maximum-length vectors. P-521 already has 528-bit vectors, so the follow-up will add the missing 256-bit P-256 and 384-bit P-384 BoringSSL cases.