Read torch rand's dtype from the argument that holds it

[LeSingh1]

Same class as #2809 — an argument read from the wrong position.

aten::rand is rand(size, *, dtype, layout, device, pin_memory), so the dtype sits right after the size. The converter unpacked:

shape, _, dtype, _, _ = _get_inputs(context, node)

which skips the dtype and reads the layout. torch always leaves the layout as None here, so the requested dtype was unreachable and every torch.rand produced fp32 whatever was asked for. Confirmed by tracing — for torch.rand(shape, dtype=torch.float16) the constants are [size, 5, None, device(cpu), False], i.e. 5 (float16) at position 1.

The lookup was wrong for the same reason: dtype.val is already a torch dtype number, so NUM_TO_DTYPE_STRING takes it directly, without the TORCH_DTYPE_TO_NUM step that only made sense for a torch.dtype object. randn, right below, already reads inputs[1].

The existing test_rand is parametrized over float16 / float32 / float64 but only checks that the samples fall in [0, 1), which holds either way.

Testing

TestRand::test_rand_dtype asserts the random_uniform dtype in the MIL program. Only the float16 case fails on main; float32, float64 and the default give fp32 either way and are there as controls. No change in the rand-family failure count (44 pre-existing on this machine, all TorchFrontend.TORCHEXPORT cases hitting a broken local scikit-learn install, which is why I could only exercise TorchScript here).