Network Security Services is the library under Firefox, Thunderbird and several Linux system components, including Firefox's WebCrypto. It works through PKCS#11: keys live in a token (the built-in softoken, or a smart card or HSM), and everything above it calls the PK11_* functions. The facts here were checked on the Alpine 3.24.2 package, NSS 3.124, initialised without a key database (NSS_NoDB_Init).
ECDSA has two layers that produce different encodings. SEC_SignData and VFY_VerifyData in cryptohi hash the message and use DER, the form X.509, CMS and OpenSSL expect. PK11_Sign and PK11_Verify take a digest and use the raw r‖s form, 64 bytes on P-256. Mixing them is the classic NSS mistake; convert with the DER ⇄ raw converter. PK11_Sign also accepted a 64-byte digest on P-256 and signed its first 32 bytes, so pass a digest that matches the curve.
Nonces are random — two signatures of the same message differed — and s is not normalized; a high-S signature verified. ECDSA with SHA-256 signed and verified on a P-384 key, so the hash is not tied to the curve. Failures are distinguishable: after VFY_VerifyData returns SECFailure, PORT_GetError() reports SEC_ERROR_BAD_DER for a raw or truncated signature and SEC_ERROR_BAD_SIGNATURE for a valid one over other data.
The softoken generated keys only on P-256, P-384 and P-521; P-224 and secp256k1 failed with SEC_ERROR_INVALID_KEY. Ed25519 works through CKM_EC_EDWARDS_KEY_PAIR_GEN and CKM_EDDSA; Ed448 does not. ML-KEM-768 encapsulation round-trips (PK11_Encapsulate, PK11_Decapsulate), while the headers declare ML-DSA mechanisms that the softoken in this build does not offer. Compare the KEM with the ML-KEM tool.