Pin the community ONNX mirrors to their own commit revisions

## 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/` → `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.