Add ml_dsa_65 (FIPS 204) to CurveType and SignatureType

[Wiezzel]

Fixes # .

Motivation

The NEAR Protocol is adding FIPS 204 ML-DSA-65 as a third transaction-signature scheme alongside ed25519 and secp256k1. Its Mesh / Rosetta RPC implementation has no way to represent post-quantum public keys or signatures at the API boundary today, because the existing CurveType and SignatureType enums are closed and only cover classical elliptic-curve and Schnorr-style schemes.

Per a thread with the Mesh-Specifications maintainers ("We would gladly accept a PR ... with the new curve type and signature type."), this PR adds the minimum needed: a single new value ml_dsa_65 in both enums. Other networks adopting post-quantum signatures (any of the FIPS 204 / FIPS 205 / FIPS 206 family) will need similar entries; landing the precedent for ML-DSA-65 first keeps that incremental.

Solution

• models/CurveType.yaml: add ml_dsa_65 to the enum and document it as a 1952-byte ML-DSA-65 public key with a pointer to FIPS 204. The field-level description also gains a note that, despite the historical name CurveType, the value may now identify a post-quantum scheme that is not based on an elliptic curve. The enum stays open-ended in spirit but remains a closed set in the spec; clients should reject unknown values exactly as they do today.
• models/SignatureType.yaml: add ml_dsa_65 to the enum and document it as a 3309-byte ML-DSA-65 signature with a pointer to FIPS 204. The signature is a fixed-size opaque byte string per FIPS 204 §3; no internal field decomposition is exposed at this layer (matching how ecdsa / ed25519 are exposed without internal structure).
• api.json: regenerated via make gen from the two YAML changes above; no hand-edits.

Backwards compatibility: pure enum addition. Clients that don't know ml_dsa_65 should reject it the same way they reject any unknown enum value; clients that do know it gain a place to put PQ keys and sigs.

Local checks run:

• make check-valid (swagger-cli validate api.yaml) — pass.
• make gen then git diff --exit-code (i.e. make check-gen) — pass after committing the regenerated api.json.
• make check-license / make spellcheck / make shellcheck — not run locally (Go-based deps not installed on dev machine); CI is expected to catch any issues. No new files were created and no existing license headers or shell scripts were touched.
• make salus — not run locally (Docker-based).

Open questions

• Naming. I chose ml_dsa_65 (snake_case, all-lowercase, matching the secp256k1_bip340 / schnorr_poseidon precedent). FIPS 204 calls the scheme "ML-DSA-65" in the spec; an alternative would be mldsa65. Happy to rename if you have a preference.
• CurveType rename. Adding a lattice scheme to a field called CurveType is a stretch. Renaming the field (or introducing a parallel PublicKeyScheme) would be cleaner but breaks every existing consumer. This PR leaves the field name alone and just notes the historical mismatch in the description — let me know if you'd rather take the breaking-change route instead.
• Companion enums for FIPS 205 (SLH-DSA) / FIPS 206 (FN-DSA). Not added here; happy to follow up if you want all three NIST-standardized PQ-DSA schemes covered in one PR rather than incrementally.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1