Add federated AMD Quark skill family

[andyluo7]

What changed

• federates all 17 public AMD Quark v0.12 skills across shared setup,
  PyTorch/Hugging Face, and ONNX workflows
• teaches the federation importer to resolve strict product-repository wrapper
  skills into standalone installable folders
• bundles adjacent resources and internal helper procedures while rewriting
  external references to the exact imported Quark commit
• adds a Quark-specific federation audit for the public skill set, commit pin,
  wrapper resolution, helper integrity, routing boundaries, safety gates,
  validator scripts, and marketplace publication
• documents the Quark family and wrapper-based federation flow and refreshes
  Claude, Cursor, and Codex plugin metadata

Why

Quark already owns a well-structured family of agent skills, but its public
.claude/skills folders are lightweight pointers into .claude/skills-impl.
Copying only those public folders would ship broken pointers. This change keeps
Quark v0.12 as the pinned source of truth while generating standalone AMD
catalog skills that can be installed individually.

The result follows a TAO-style multi-skill family without creating model- or
quantization-scheme-specific skill sprawl: backend and lifecycle boundaries
remain explicit, and expensive PTQ or AutoSearch execution remains
confirmation-gated.

Validation

• UV_SYSTEM_CERTS=true bash .github/scripts/check.sh (24 skills)
• Quark federation audit (17 public skills)
• uvx --system-certs ruff check ... and ruff format --check ... for the
  authored federation scripts
• Torch result-validator self-test
• ONNX result-validator self-test with onnx>=1.21.0,<=1.22.0
• npx --yes skills add . --list (24 skills discovered)
• git diff --check origin/main...HEAD

This is the Quark-only half of the split requested on #119. The
amd-skill-finder change remains in #119 and is not part of this diff.

[amd-zhaofeng]

Thanks for taking on the work of bringing Quark's skills into the catalog — this is something we have wanted to see happen. We are on the Quark team, and having read through it there is one structural concern we would like to raise:

This integration writes Quark's internal layout, the v0.12 version and a set of internal skill names into the catalog's own importer and CI, which couples the two tightly: anything that moves on the Quark side means redoing the work here.

A safer shape would follow magpie-kernel-evaluator and tracelens-analysis-orchestrator: the source repository maintains a small number of self-contained entry-point skills, sources.yml declares only the repo, the ref and the folder names, the importer copies them as they are, and the catalog carries no product-specific logic.