chore: benchmark pub randomness commit

[Lazar955]

For numPubRand ≤ 1000, the growth appears roughly linear, with execution time increasing by similar factors as numPubRand

---

Benchmark ran on M3 Pro.

numPubRand	Iterations (b.N)	Time per Iteration (ns/op)	Approx. Time (ms)	Approx. Time (s)
10	38	29,210,366	~29.2 ms	~0.03 s
50	16	68,297,312	~68.3 ms	~0.07 s
100	9	120,456,028	~120.5 ms	~0.12 s
200	5	224,715,767	~224.7 ms	~0.22 s
500	2	536,105,584	~536.1 ms	~0.54 s
1,000	1	1,056,664,416	~1.1 s	~1.1 s
5,000	1	5,159,288,750	~5.2 s	~5.2 s
10,000	1	10,353,431,958	~10.4 s	~10.4 s
25,000	1	26,828,946,167	~26.8 s	~26.8 s
50,000	1	53,123,792,875	~53.1 s	~53.1 s
75,000	1	156,188,836,166	~156.2 s	~2.6 m
100,000	1	211,468,613,458	~211.5 s	~3.5 m

---

---

References issue

[gitferry]

Very nice work!

Ideally, for 1 week usage, the fp needs 70k randomness, which costs roughly 2min from the results (had some rough analysis in https://github.com/babylonlabs-io/pm/blob/be599cf457bbd892d28cb2d4d54c0f0d448c71d1/adr/adr-024-timestamping-public-randomness.md#L127).

I think this is acceptible. cc @SebastianElvis @KonradStaniec @filippos47

Could you also benchmark the proof saving time (maybe in a seprate pr)? Probably db access is the bottleneck