Add stage and source fields to file-validation-error telemetry

[stevenweaver]

Summary

Follow-up to #136. After last week's classifier expansion + message capture, ~1k validation errors / 30 days still fire and we don't have a clean way to tell upstream-of-HyPhy failures (Aioli mount/exec, IndexedDB quota) apart from downstream user-data failures (HyPhy datareader rejections). String-matching can only get us so far.

This adds two structural fields to the `file-validation-error` payload so the bucket can be split by axis instead:

• `stage` — `'init' | 'storage' | 'mount' | 'exec' | 'download' | 'parse' | 'datareader-error'`. Tracks which awaited step in `handleFileUpload` threw, via a `currentStage` let-binding updated before each major await.
• `source` — `'upload' | 'reselect' | 'demo' | 'repair'`. Tracks which entry point triggered validation. Derived from the existing `event.isSelection` / `event.isDemo` flags; `handleUseRepaired` now passes `isRepaired: true` so the repair path is distinguishable.

No fix here, just visibility. Once a week of data comes in, the `stage` × `errorType` cross-tab in Umami should make it obvious whether to expand the classifier (data errors) or chase infra (mount/exec failures).

Test plan

• All 201 existing tests pass
• Manual: trigger each entry point (upload, history reselect, demo, repair) — confirm Umami receives the expected `source`
• Manual: force a HyPhy error (e.g. stop-codon file) — confirm `stage: 'datareader-error'`
• Manual: force a quota error (fill IndexedDB in devtools) — confirm `stage: 'storage'`

Follow-ups

• After a few days of telemetry, decide whether to (a) expand the classifier based on captured messages, or (b) chase whichever infra stage shows up disproportionately.
• The `runtime-error` bucket added in PR previously may now be partially redundant with `stage: 'mount' | 'exec'` — worth reviewing once data is in.