Federate serving-llms-on-epyc from amd/ZenDNN-pytorch-plugin

[amd-lalithnc]

Adds amd/ZenDNN-pytorch-plugin as a federation source, so the nightly import vendors serving-llms-on-epyc from zentorch, which becomes its source of truth. The skill keeps its current name, so existing installs keep working.

Merge once the skill is on amd/ZenDNN-pytorch-plugin main, expected Thursday, Oct 8 via zentorch's weekly public sync. Until then, the nightly import would fail with "has no SKILL.md".

Needs product-repo approval for amd/ZenDNN-pytorch-plugin; the federation guard flags it until then.

The first import also brings two small changes made on the zentorch side: flake8 fixes in the scripts (no behavior change), and the skill card's license set to Apache-2.0, zentorch's license. It adds the skill back to the amd-skills marketplace bundle for Claude, Cursor, and Codex. evals/ stays as amd/skills' own copy.

Testing

• federate_skills.py --check-catalog: valid, 3 skills declared.
• federation_guard.py on this diff: no edits to vendored skills; only the expected approval flag.
• Simulated nightly import against the zentorch branch: vendors the skill as-is, adds it to the marketplace bundle, and check.sh passes on the result.

Change-Id: I0a6c0bdbeae8a7a906b386962a653dcf7ae1b668

[github-actions]

Product repo approval required

No entry in .github/skill_owners.json covers these skills, so they cannot be federated yet:

• serving-llms-on-epyc from amd/ZenDNN-pytorch-plugin/skills/serving-llms-on-epyc

1. Open a Product repo approval issue for amd/ZenDNN-pytorch-plugin. If the repo is a super-repo of unrelated projects, name the project's directory instead, as owner/repo/sub/dir.
2. The engineering owner and the product release owner each comment /approve on it.
3. Merge the registry pull request that opens, then push here again.

Skills already in the catalog are unaffected; this applies to the ones this pull request adds.