feat(model): curate the built-in catalog by hardware target

[rominf]

What

rocm model dumped every built-in recipe as a flat list — including tiny smoke/test paths — and didn't say what the list was for. This turns it into a short, curated catalog of current popular open-weight models, grouped by the hardware path each targets, with each entry sized to a quantization that fits a single GPU (multi-GPU serving isn't supported).

Recommended models — run one with `rocm serve <model>`

Strix Halo (Lemonade / llama.cpp)
  unsloth/Qwen3.6-35B-A3B-GGUF:Q4_K_M  Q4_K_M GGUF, ~22 GiB
  unsloth/gemma-4-26B-A4B-it-GGUF:Q4_K_M  Q4_K_M GGUF, ~17 GiB

MI300X (vLLM)
  Qwen/Qwen3.6-27B  BF16, ~54 GiB (1x MI300X)
  google/gemma-4-31B-it  BF16, ~62 GiB (1x MI300X)

These are recommendations — you can serve any compatible Hugging Face model:
  rocm serve <owner/repo>          # vLLM, e.g. Qwen/Qwen3.6-27B
  rocm serve <owner/repo>:<quant>  # Lemonade GGUF, e.g. unsloth/Qwen3.6-35B-A3B-GGUF:Q4_K_M

Use `rocm model --verbose` for details.

How

• The built-in list is now an embedded JSON file (model_catalog.json) using the same schema as a signed recipe index, so the offline default and hosted indexes share one format and the catalog is easy to curate. A unit test parses and validates it, so a malformed catalog can't ship.
• Featured models use canonical Hugging Face ids with the quant that fits one GPU. Strix Halo entries use the owner/repo:variant GGUF form that rocm serve needs (via the Lemonade canonical-name serving path); MI300X entries serve at BF16.
• rocm model shows only the curated featured list for the built-in catalog, grouped by hardware target, plus a note that any compatible Hugging Face model can be served. A configured recipe index is shown in full and named in the header.
• The default assistant, smoke/test, and superseded recipes stay fully resolvable for rocm serve and are listed under rocm model --verbose (annotated as hidden) — nothing is removed from resolution.

Testing

• cargo test -p rocm-core (incl. catalog parse/validate + featured/platform helpers) and cargo test -p rocm --bin rocm model pass.
• cargo clippy / cargo fmt clean.

[juhovainio]

Overall the design is clean — embedding a JSON catalog, parsing it once with OnceLock, and reusing the existing recipe-index schema is a good approach. A few findings below, ranging from a medium bug to a doc nit.

[juhovainio]

Two follow-up suggestions for this PR or a future iteration:

1. Move platform definitions into model_catalog.json

MODEL_CATALOG_PLATFORMS is currently a hardcoded &[&str] in lib.rs, and model_recipe_target_platform maps engine names to those strings with a match arm. This has the same sync-drift risk as the FEATURED_MODEL_IDS constant. A top-level platforms array in the JSON (alongside recipes) would keep everything in one place:

"platforms": [
  {
    "label": "Strix Halo (Lemonade / llama.cpp)",
    "engines": ["lemonade", "llama.cpp", "llamacpp"],
    "gfx_families": ["gfx120X-all"]
  },
  {
    "label": "MI300X (vLLM)",
    "engines": ["vllm"],
    "gfx_families": ["gfx906", "gfx908", "gfx90a", "gfx90a-all"]
  }
]

model_recipe_target_platform would then look up the recipe's first preferred engine against this list instead of a hardcoded constant. Adding a new hardware target in future only requires a JSON edit.

2. Highlight the current platform in rocm model output

The gfx target detection already exists (detect_host_gfx_target + normalize_therock_family, the same probe rocm examine uses). If render_model_registry_text_with_context_and_host called it and matched the result against each platform's gfx_families, the matching platform header could be annotated — e.g.:

Strix Halo (Lemonade / llama.cpp)  ← your GPU
  unsloth/Qwen3.6-35B-A3B-GGUF:Q4_K_M  ...

MI300X (vLLM)
  Qwen/Qwen3.6-27B  ...

This makes it immediately clear which section is relevant for the user's hardware without them having to know which GPU maps to which platform. The detection is a fast sysfs read on Linux / WMI probe on Windows, same cost as rocm examine.