Pin the community ONNX mirrors to their own commit revisions

[jeremymanning]

What

In the static build, in-browser generation resolves the community ONNX mirror (e.g. onnx-community/gpt2-ONNX) at main. Everything else the site fetches is pinned: the tokenizer and the safetensors weight windows both use the model repo's recorded commit SHA.

This is the one path where the bytes executed in a visitor's browser can change without a code change here.

Why it isn't already fixed

The obvious fix — pass the recorded revision through to pipeline(...) — is wrong, and was measured to be wrong:

Could not locate file: "https://huggingface.co/onnx-community/gpt2-ONNX/resolve/607a30d783dfa663caf39e06633721c8d4cfcd7e/tokenizer.json"

607a30d7… is gpt2's commit. The ONNX mirror is a different repository with its own commit history, so the model repo's SHA 404s against it. Attempting this broke generation entirely until it was reverted.

What a real fix looks like

Record each mirror's own revision:

1. Resolve the mirror's head SHA at export time (GET https://huggingface.co/api/models/<mirror> → sha), for the mirrors listed in ONNX_REPOS (code/frontend/src/lib/staticClient/arch.ts).
2. Write it into the per-model meta.json the exporter emits (e.g. onnx_repo + onnx_revision), so the mapping lives with the data rather than hard-coded in the frontend.
3. Pass that SHA to pipeline(..., { revision }) in transformersRuntime.ts.

Step 2 is the substantive one: it also removes the hard-coded ONNX_REPOS map from the frontend, which is currently a second place the curated model list has to be kept in sync.

Acceptance

• Generation resolves a pinned SHA, verified in a browser (not just in types).
• A stale/incorrect SHA fails loudly at load with a plain-language error, not a hang.
• The curated model list has exactly one source of truth.