Weight shorter traces higher in randomized trace selection

[Copilot]

Randomized trace generation was producing quite long traces with equal probability. This change introduces weighted selection that slightly prefers shorter traces while still allowing longer ones.

Changes

• New weighted_trace_choice() in spotutils.py: Uses inverse step count weighting (1 / (1 + num_steps)) instead of uniform random.choice()
• Semantic step counting: Counts trace steps by ; delimiter rather than character length (e.g., 'a; b; cycle{c}' = 3 steps)
• Updated trace selection in exercisebuilder.py (2 locations) and app.py (1 location)

Example

# For traces with 1, 3, 4, 5... steps:
# step=1:  weight=0.50  → ~27% selection
# step=3:  weight=0.25  → ~10% selection  
# step=11: weight=0.08  → ~5% selection

All traces remain selectable; shorter ones are just more likely.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Randomized trace gen leads to quite long traces</issue_title>
<issue_description>New randomized trace gen approach leads to quite long traces. Perhaps we should slightly prefer shorter traces when choosing. That is, still allow longer traces, but weight shorter traces SLIGHTLY higher in the random gen.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Randomized trace gen leads to quite long traces #116

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[sidprasad]

@copilot instead of counting the LENGTH of a trace for weighting, it should be the number of states in the trace. I think ; count is a good proxy for this