Description

wc_CryptoCb_Curve25519MakePub() took no devId. It looked up INVALID_DEVID and then fell back to wc_CryptoCb_FindDeviceByIndex(0), so it always landed on whichever device was registered first. Every route to an X25519 public point derivation went through it, so a key created with wc_curve25519_init_ex(&key, heap, myDevId) had its private scalar offered to a device the application never selected, with no way to opt out. wc_CryptoCb_Curve25519Generic() had the same shape. This mirrors what #11209 did for curve448.

• Both functions take a leading int devId, and the index-0 fallback is gated on devId == INVALID_DEVID. Both are WOLFSSL_LOCAL, so no public ABI change.
• wc_curve25519_make_key() and wc_curve25519_export_public_ex() derive the point through a new curve25519_key_make_pub() that passes the key's devId and only allows the callback when the key is actually bound to a device. The keyless public API keeps its old behaviour, having no key to take a devId from.
• Under WOLFSSL_CURVE25519_BLINDING both wc_curve25519_make_pub() and wc_curve25519_generic() fall through to their blinded variant after the callback declines, and that variant dispatched to the same device again, showing a declining device the scalar twice. The inner call now runs with the callback disabled.

Second commit, independent: curve25519_keyagree_test() fills pubKey inside a block guarded on HAVE_CURVE25519_KEY_EXPORT, but the block computing a shared secret against pubKey required only the import, so NO_CURVE25519_KEY_EXPORT builds failed in testwolfcrypt. curve448_keyagree_test() has the identical defect. Both consuming guards now require the export.

Behaviour change: under WOLF_CRYPTO_CB_ONLY_CURVE25519, an unbound key passed to wc_curve25519_export_public_ex() now returns NO_VALID_DEVID instead of reaching the first registered device, since there is no software fallback. Such builds must use wc_curve25519_init_ex() with a real devId. wc_curve25519_make_key() already behaved this way. Documented as a \return.

Testing

New test_wc_curve25519_cryptocb registers two spy devices, the decoy first so it holds the slot the old fallback would have picked, and covers a key bound to device A (B sees nothing), a key naming an unregistered devId, an unbound key on both the keygen and export paths, and the keyless APIs. Each derived point is compared against the one keygen produced.

Proofs rather than claims:

• Reverting just the && (devId == INVALID_DEVID) term makes the new test fail; restoring it passes.
• A callback that declines everything was dispatched 2x per call before the blinding fix and 1x after.
• The new MC/DC vector in test_cryptocb_whitebox.c uses WB_DEVID_NOCB so the first two operands genuinely sit at (F,T) and only the third changes, giving unique-cause rather than masking MC/DC. Confirmed by instrumenting the decision.

make check green (17 pass / 6 skip / 0 fail) on --enable-all --enable-cryptocb and on the same with --disable-armasm. The second leg matters: WOLFSSL_CURVE25519_BLINDING is only auto-enabled when ARMASM is off, so on aarch64 a plain --enable-all compiles none of the blinded paths this PR touches. testwolfcrypt also passes with -DNO_CURVE25519_KEY_EXPORT and with -DNO_CURVE448_KEY_EXPORT.

New CI entry cryptocb-curve25519-no-key-export covers a build with the X25519 export compiled out, which nothing in CI compiled before. wolfCrypt only, because src/internal.c and src/tls.c call wc_curve25519_export_public_ex() unconditionally and TLS cannot link without it. It carries its own cflags adding -Werror (a per-entry value replaces the job's --cflags), so an unreferenced static fails the build. Narrowing curve25519_key_make_pub()'s guard makes that entry fail, so it has teeth.