fix(sampling): use an unbiased, seedable shuffle for random question selection

[Agnik47]

Fixes #72.

Problem

Random sampling shuffled with an inconsistent comparator:

// src/orchestrator/index.ts:56 — and again, verbatim, in src/orchestrator/batch.ts:74
const shuffled = [...questions].sort(() => Math.random() - 0.5)
selected.push(...shuffled.slice(0, sampling.perCategory).map((q) => q.questionId))

The comparator ignores its arguments, so it violates the consistency Array.prototype.sort requires and the resulting permutation is engine-dependent. In practice elements stay near their original positions far more often than chance — and since the sampler then takes the first N of the shuffled array, the bias lands squarely on the selected slice.

Measured over 12,000 trials on a 6-element array (expected 2,000 per element/position cell):

	min cell	max cell
sort(() => Math.random() - 0.5)	1,250	3,041
Fisher–Yates	1,929	2,078

One element held its original position 25.3% of the time against an expected 16.7%. So --sample-type random kept picking the same front-of-dataset questions, and a sample's accuracy was not an unbiased estimate of the full-run accuracy it stands in for. There was no seed either, so the selection was neither uniform nor reproducible.

The same code existed in two places — the single-run orchestrator and the batch compare path — so fixing one would have left the other biased.

Fix

• New src/orchestrator/sampling.ts with a Fisher–Yates shuffle driven by a seedable mulberry32 PRNG, plus the shared selectQuestionsBySampling. Both call sites now use it, removing the duplicated logic.
• --seed N on run and compare reproduces a previous selection. Invalid seeds are rejected at parse time rather than surfacing mid-run.
• When no seed is given, one is generated, logged (Random sampling seed: 1234 (reuse with --seed 1234)) and stored in SamplingConfig.seed — in the run checkpoint and in the compare manifest — so a past sampled run can be re-selected question-for-question.
• Category buckets moved from a plain object to a Map, so integer-like question types keep insertion order instead of being hoisted to the front.

Behaviour is unchanged for mode: "full", mode: "limit" and sampleType: "consecutive".

Tests

New src/orchestrator/sampling.test.ts (16 tests, bun test):

• every element lands in every position equally often (max deviation < 150 over 12,000 seeded trials, ~3.7σ — deterministic, so it cannot flake)
• a characterisation test pinning the bias of the sort(() => Math.random() - 0.5) it replaces
• same seed reproduces the same subset in the same order; different seeds diverge
• a run given no seed reports one that replays its exact selection
• across 200 seeds every question in the pool is reachable — the front-loading is gone
• full / limit / consecutive selection, undersized categories, empty and single-element inputs, PRNG range and reproducibility

Reverting shuffle to the old expression fails 3 of them; all 16 pass with the fix.

bunx tsc --noEmit is clean and both new files are Prettier-clean. The five touched files already fail bun run format:check on main (as do ~69 others), so I left their pre-existing formatting alone to keep the diff scoped.