The core's ek_rd_addr/dkp_rd_addr muxes give dbg_dk_idx_i priority over
dbg_byte_idx_i whenever it falls in the ek (768..1567) or dk_pke (<768)
region. The wrapper drove both dbg_byte_idx_i and dbg_dk_idx_i from the
same rdb_addr, so an ek readback of the rho tail (bytes 768..799) was
hijacked to read ek[0..31] instead — corrupting the public key fed to
Encaps and causing Decaps implicit rejection (full 32-byte ss mismatch).
Present rdb_addr on dbg_dk_idx_i only when rdb_sel==2 (full-dk); hold it
at 0xFFF otherwise so ek/dk_pke readbacks aren't corrupted. Verified by
KeyGen->Encaps->Decaps round trip (MLKEM_RESULT=PASS).
Wrap mlkem_top in an AXI4 burst slave (mlkem_axi_slave) mapped to the
freed FFT slot 6 at 0x1f400000 (virtual 0xbf400000). The core runs on
sys_clk/2 (25 MHz); the wrapper handles the clock-domain crossing:
start toggle->pulse, wait-stated byte-preload handshake, busy/done
sync, and direct readback taps (ek/dk/ct/ss). CPU drives it via a
register map (CTRL/STATUS/CONFIG, d/z/msg, preload + readback windows).
Wire into soc_top on the existing axiOut_6 nets (no crossbar change),
add mlkem_intr on intrpt[3]. Add sdk mlkem_test example running a
KeyGen->Encaps->Decaps self-consistency round trip.
