Verify the MIMXRT1064-EVK TRNG bring-up on hardware #70

The i.MX RT1064 TRNG driver added in #66 (targets/NXP/MIMXRT1064-EVK/app/trng.c) is written against the reference manual but has never run on silicon, and the CI suite cannot tell whether it is correct.

Renode's IMX_TRNG model implements neither half of the sequence the driver depends on. It logs Unhandled write for MCTL[PRGM], MCTL[RST_DEF] and SDCTL[SAMP_SIZE]/SDCTL[ENT_DLY], so the programming-mode bring-up is a no-op there. It also returns a fresh pseudo-random word on any ENT[n] read, where silicon refills the block only when ENT15 is read and re-arms ENT_VAL. A driver that skipped the bring-up entirely, or that read ENT[0] in a loop and returned the same word every time, would pass the current tests identically.

What would settle it, on a physical MIMXRT1064-EVK:

• MCTL[ENT_VAL] clears after ENT15 is read and sets again on the next round.
• Successive trng_get_random_u32 calls return distinct words across several full 16-word blocks, rather than one repeating value.
• MCTL[ERR] stays clear through the PRGM -> RST_DEF -> SDCTL -> run-mode transition in trng_init.
• Entropy survives a basic sanity check over a few kilobytes. A repeating four-byte pattern is the failure mode this is guarding against.

A TRNG that repeats looks fine in a demo and is fatal in whatever product copies the demo, which is why this wants a board rather than another emulator run. The README records the limitation in the meantime.