[david415]

FIPS203.dummyPk, dummySk and dummyCt were made by running ML-KEM keygen and encapsulation on a zero seed. They are only the Inhabited witnesses in each scheme's KEM record, but the records are top-level values, so every executable importing KEM.Schemes ran keygen and encaps for all six ML-KEM variants (plain and hedged, 512/768/1024) when it started. In huh, initialize_cryptlib_Cryptlib_Primitives_KEM_Schemes was 83% of startup.

The dummies are now zero bytes of the sizes the subtypes require, built with bytesT/bytesU/bytesV; the size proofs are by simp. Nothing used their values.

	before	after
huh --help (process start)	345 ms	47 ms
huh 127.0.0.1 true over TCP	~450 ms	~125 ms
huh 127.0.0.1 true over QUIC	~700 ms	~330–460 ms

make test passes, including the ML-KEM and hedged ML-KEM vectors.

Not changed: KEM.Adapter.kemOfNike still derives its default public key with derivePublicKey on a zero seed (an X25519 scalar multiplication for the X25519 KEMs).