Potential race conditions in both C testfloat3 and Go rand number generators

I am seeing inconsistent `.quad` values between compilations, even though I use fixed seeds. The issue are race conditions caused by multiple goroutines accessing the shared number generator in different orders and resets in between.

What I think is happening:
Multiple goroutines call (indirectly via main) `testfloat3.InitF16()` , and that function calls srand(2024). At the same time, Go’s `genRandomData`() calls `rand.Seed(n)`.

Due to the parallelization of the loop with goroutines, these generators are reset and consumed simultaneously. The seeds are deterministic, but the access pattern is not, which leads to non deterministic sequences.

For context: I have customized the script to only test the "vd, vs2, vm" format, and I have added a few new instructions that do not have default test case values. So the source register data is completely random

Start by tracing main's goroutines into testfloat3.InitF16() and Go genRandomData(), focusing on their calls to srand(2024) and rand.Seed(n). Reproduce the inconsistent .quad values with the parallel loop and fixed seeds; done should establish deterministic generator behavior under the reported concurrent execution.

Written by the indexing model from the issue text.