[RNE Rewrite] Update huggingface model cards

[msluszniak]

We need to update HF models cards as some seems be outdated, they are not in the same style. This should unify them all.

[msluszniak]

@barhanc I think we should establish some template for that and add this maybe to spec repository on HF, wdyt?

[msluszniak]

@barhanc WDYT about this template:

Model card standard

Every software-mansion/react-native-executorch-* repository carries a
README.md in this shape. Four sections are generated from the repository
tree and its config.json files, so they cannot drift from what is published.
Anything a model needs beyond them is a free section, written by hand and
kept as-is.

Before this standard the estate had 12 distinct heading sequences, four
heading-level conventions, and five different ExecuTorch versions claimed in
prose while 28 of 54 cards claimed none.

Front matter

Hugging Face card metadata. Required on every repository:

key	value
license	An SPDX-style Hub identifier for the upstream license, not ours. Use other plus license_name and license_link when the upstream license has no Hub identifier.
pipeline_tag	The Hub task this model serves, so it appears in task search.
library_name	Always executorch.

Optional: base_model, language, tags. Keep the same identifier here and in
the license field of every config.json in the repository; they are checked
against each other.

Generated sections

1. Title and introduction

The # title is the repository slug with the react-native-executorch-
prefix dropped. One paragraph naming the library, then the upstream model on
its own line:

# <slug>

This repository hosts the **<slug>** models exported for the
[React Native ExecuTorch](https://www.npmjs.com/package/react-native-executorch)
library as ExecuTorch `.pte` programs, ready to run on device.

Upstream model: [<name>](<url>)

Omit the upstream line when there is no single upstream to point at, rather
than guessing a URL.

2. Variants

One row per published .pte, read from the variants array of every
config.json. Multi-component variants contribute one row per component.

## Variants

| Path | Backend | Precision |
| --- | --- | --- |
| `xnnpack/model_xnnpack_fp32.pte` | xnnpack | fp32 |
| `xnnpack/model_xnnpack_int8.pte` | xnnpack | int8 |
| `coreml/model_coreml_fp16.pte` | coreml | fp16 |

The precision token is the whole story: precisions.json is authoritative for
which tokens are quantized, so the card does not repeat that partition. Nor
does it name a default, because the library resolves one per platform and a
second answer here would only compete with it.

3. Repository structure

Every tracked file except README.md and dotfiles, with its size, so a reader
can see the download cost before fetching.

## Repository structure

​```
coreml/config.json                 1 kB
coreml/model_coreml_fp16.pte       8.3 MB
xnnpack/config.json                3 kB
xnnpack/model_xnnpack_fp32.pte     31.1 MB
​```

Sizes render as B, kB, MB or GB.

4. Compatibility

Fixed text, parameterised only by the bundled ExecuTorch version. It states
the runtime the files are published for, and deliberately does not claim
the version each file was exported with: that is unrecorded for older exports,
and the five conflicting numbers the cards used to carry were all stale.

## Compatibility

These files are published for the **ExecuTorch v1.4.1** runtime that
react-native-executorch 0.10 bundles. ExecuTorch gives no forward
compatibility guarantee, so an older runtime may fail to load them.

Using them through [React Native ExecuTorch](https://www.npmjs.com/package/react-native-executorch)
needs nothing further: the model constants it ships resolve to files matching
the runtime it bundles. See the
[documentation](https://docs.swmansion.com/react-native-executorch/) for the
API.

To load these files in your own ExecuTorch runtime, read the
[compatibility note](https://github.com/pytorch/executorch/blob/main/runtime/COMPATIBILITY.md)
first.

Bump the version here whenever the bundled runtime changes.

Free sections

Everything a model needs that the skeleton cannot express, appended after
Compatibility at ## level and left exactly as written. Existing examples:

• Methods & I/O contract, Output contract, Pipeline contract — what the
  methods take and return, and what normalisation the caller owes.
• Shape discovery (get_model_schema) — models exporting a schema method.
• Model details, Export notes, CoreML notes (iOS) — export decisions and
  per-backend caveats worth keeping.
• Backends, sizes & latency (warm) — measured numbers.
• Languages, Classes (N) — enumerations too long for the introduction.

Write a free section whenever the answer to "how do I call this correctly?"
does not follow from the variant table. Do not restate anything the generated
sections already cover.

Rules

1. Heading levels are fixed: one # title, everything else ##.
2. Never hand-edit a generated section. Fix the tree or the config.json and
   re-render, so the card and the artifacts cannot disagree.
3. One ExecuTorch version appears in a card, in Compatibility.
4. Free sections carry the model-specific truth. Boilerplate belongs in the
   generated skeleton, where it is written once.
5. Nothing in a card restates a fact the artifacts already hold. Derive it
   instead, so the two cannot disagree.

[barhanc]

In general looks good.

• In the compatibility template I'm not sure about this fragment 'that react-native-executorch 0.10 bundles' - it will require updating after every version release even if neither the ExecuTorch version changed nor the model was re-exported.
• Specifying the i/o contract in free section goes against the 5-th rule as there are the .jsons (although we currently have two different ones -- the schema.json and the older one that only reports upper bounds for dims).
• Model details I would put only if the model is niche or the upstream link doesn't already cover it. Same goes for stuff like languages, classes, etc. -- I feel like for most models it's easily checkable so no need to duplicate that information. About adding the required preprocessing info I'm not sure -- it's already declared in the models.ts but maybe adding it again here would have some benefits?
• I'm not sure about the things like model latency, benchmarks there. I'm not sure anyone would actually think to look into model card for these, rather than e.g. docs page. Export notes on the other hand are a very good idea to place them in one place.
• Maybe rephrase this

  Using them through [React Native ExecuTorch](https://www.npmjs.com/package/react-native-executorch)
  needs nothing further: the model constants it ships resolve to files matching
  the runtime it bundles. See the
  [documentation](https://docs.swmansion.com/react-native-executorch/) for the API.
  

  to

  To use them in React Native ExecuTorch simply pass the model constant shipped in the library's model registry to the corresponding task pipeline. See [link to model registry api reference or just docs].
  

  so it doesn't have the LLM-isms.