Reader never validates DMSGF_SIZE against the base command — undersized extended headers reach command dispatch (latent type confusion)

Summary

kdmsg_iocom_thread_rd accepts any DMSGF_SIZE (1..32 = 64..2048 bytes) for any base command and sizes the kdmsg_msg allocation from the wire SIZE alone; nothing verifies the header carries the structure the base command implies. Today's consumers are mostly protected by accident (tcmd constants embed canonical SIZE; default cases reject); subr_diskiocom dispatches on state->rxcmd so mid-stream undersized messages still reach disk handlers, but their deepest field reads stay inside the 120-byte SIZE=1 allocation. No OOB demonstrable with current consumers; structural hazard for any future deep-reading handler. Size-vs-command table fix proposed.