feat(visualization): seed Word Cloud and Network Graph so a rerun draws the same picture

[kz930]

What changes were proposed in this PR?

Word Cloud and Network Graph both lay their output out from an unseeded generator, so running the same workflow twice draws two different pictures of the same data. Word Cloud built its image without random_state, and Network Graph called nx.spring_layout without seed. This passes a fixed seed in both.

Only the arrangement was moving. Which words appear and how large they are is decided by frequency alone, and the graph's nodes and edges are likewise unaffected, so no analysis changes. What changes is that a saved screenshot keeps matching what the operator produces, and two people opening the same workflow see the same picture. Every other visualization in Texera already behaves this way.

The issue offered a second option, exposing the seed as a user setting. This takes the smaller one: a fixed default with no new setting. Existing workflows render one last different picture and are stable from then on.

Any related issues, documentation, discussions?

Closes #7326

How was this PR tested?

WordCloudOpDescSpec and NetworkGraphOpDescSpec each gain a case asserting the generated Python carries the seed. The Network Graph one reads the nx.spring_layout line rather than matching the whole call, so it survives a change to k or iterations. Both suites pass, 11 tests.

The seed was also checked against the libraries themselves, outside the operators: rendering the same text twice through WordCloud gives two different PNGs unseeded and byte-identical ones with random_state=0, and nx.spring_layout on the same graph gives different node coordinates unseeded and identical ones with seed=0.

Was this PR authored or co-authored using generative AI tooling?

Generated-by: Claude Code (Claude Opus 5)

[github-actions]

Automated Reviewer Suggestions

Based on the git blame history of the changed files, we recommend the following reviewers:

• Contributors with relevant context: @eugenegujing, @bobbai00
  You can notify them by mentioning @eugenegujing, @bobbai00 in a comment.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.80%. Comparing base (133da7b) to head (ce8e503).

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #7533      +/-   ##
============================================
- Coverage     86.80%   86.80%   -0.01%     
  Complexity     4226     4226              
============================================
  Files          1173     1173              
  Lines         46865    46865              
  Branches       5231     5231              
============================================
- Hits          40682    40679       -3     
- Misses         4457     4460       +3     
  Partials       1726     1726              

Flag	Coverage Δ		*Carryforward flag
access-control-service	70.00% <ø> (ø)
agent-service	89.01% <ø> (ø)		Carriedforward from 133da7b
amber	82.11% <100.00%> (-0.02%)	⬇️
computing-unit-managing-service	60.38% <ø> (ø)
config-service	65.97% <ø> (ø)
file-service	69.05% <ø> (ø)
frontend	89.47% <ø> (ø)		Carriedforward from 133da7b
notebook-migration-service	78.89% <ø> (ø)
pyamber	97.52% <ø> (ø)		Carriedforward from 133da7b
workflow-compiling-service	26.31% <ø> (ø)

*This pull request uses carry forward flags. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

⚠️ Benchmark changes need a look

🟢 4 better · 🔴 8 worse · ⚪ 3 noise (<±5%) · 0 without baseline

Compared against main 133da7b benchmarked on this same runner, so the delta is largely free of cross-runner hardware noise. The "7d avg" column still reflects the gh-pages dashboard. Treat <±5% as noise unless repeated.

Dashboard · Run

	config	throughput	MB/s	latency	max Δ latest / 7d
🔴	bs=10 sw=10 sl=64	370	0.226	24,954/36,675/36,675 us	🔴 +21.3% / 🔴 +129.3%
🔴	bs=100 sw=10 sl=64	891	0.544	107,958/146,357/146,357 us	🟢 -11.1% / 🔴 +35.4%
🟢	bs=1000 sw=10 sl=64	1,087	0.663	917,147/978,645/978,645 us	🟢 -5.5% / 🟢 -8.4%

Baseline details

Latest main 133da7b from same runner

config	metric	PR	latest main	7d avg	Δ latest	Δ 7d
bs=10 sw=10 sl=64	throughput	370 tuples/sec	450 tuples/sec	784.3 tuples/sec	-17.8%	-52.8%
bs=10 sw=10 sl=64	MB/s	0.226 MB/s	0.275 MB/s	0.479 MB/s	-17.8%	-52.8%
bs=10 sw=10 sl=64	p50	24,954 us	20,572 us	12,590 us	+21.3%	+98.2%
bs=10 sw=10 sl=64	p95	36,675 us	33,247 us	15,991 us	+10.3%	+129.3%
bs=10 sw=10 sl=64	p99	36,675 us	33,247 us	18,694 us	+10.3%	+96.2%
bs=100 sw=10 sl=64	throughput	891 tuples/sec	951 tuples/sec	1,002 tuples/sec	-6.3%	-11.1%
bs=100 sw=10 sl=64	MB/s	0.544 MB/s	0.58 MB/s	0.612 MB/s	-6.2%	-11.0%
bs=100 sw=10 sl=64	p50	107,958 us	101,612 us	101,285 us	+6.2%	+6.6%
bs=100 sw=10 sl=64	p95	146,357 us	164,697 us	108,068 us	-11.1%	+35.4%
bs=100 sw=10 sl=64	p99	146,357 us	164,697 us	118,235 us	-11.1%	+23.8%
bs=1000 sw=10 sl=64	throughput	1,087 tuples/sec	1,078 tuples/sec	1,030 tuples/sec	+0.8%	+5.5%
bs=1000 sw=10 sl=64	MB/s	0.663 MB/s	0.658 MB/s	0.629 MB/s	+0.8%	+5.5%
bs=1000 sw=10 sl=64	p50	917,147 us	924,715 us	991,882 us	-0.8%	-7.5%
bs=1000 sw=10 sl=64	p95	978,645 us	1,035,355 us	1,038,496 us	-5.5%	-5.8%
bs=1000 sw=10 sl=64	p99	978,645 us	1,035,355 us	1,068,265 us	-5.5%	-8.4%

Raw CSV

config_idx,batch_size,schema_width,string_len,num_batches,total_ms,total_tuples,total_bytes,tuples_per_sec,mb_per_sec,lat_p50_us,lat_p95_us,lat_p99_us
0,10,10,64,20,540.05,200,128000,370,0.226,24953.79,36674.87,36674.87
1,100,10,64,20,2244.55,2000,1280000,891,0.544,107957.57,146356.77,146356.77
2,1000,10,64,20,18400.27,20000,12800000,1087,0.663,917146.77,978645.32,978645.32

[kz930]

@carloea2 @bobbai00 May you take a look at this?

[carloea2]

Looks good to me.