fix: resolve skills by frontmatter name

[SungKyeol]

Summary

• Fix skill_view() so it can resolve skills by the canonical name: in SKILL.md frontmatter, not only by directory name.
• Add a regression test for the case where a skill directory name differs from its frontmatter name.

Core bug

skills_list used the frontmatter name, while skill_view used the directory name.

That meant the same skill system could expose a name that was not actually loadable:

visible name != loadable name

For example, a skill stored under a directory like brainstorming/ but declaring:

name: superpowers-brainstorming

could appear in skill listings or autocomplete as superpowers-brainstorming, but skill_view("superpowers-brainstorming") failed because lookup only matched the directory name.

Fix

When scanning SKILL.md files, skill_view() now matches either:

1. the containing directory name, or
2. the name: value from the skill frontmatter.

This keeps listing and loading behavior consistent.

Tests

• python -m pytest tests/tools/test_skills_tool.py tests/test_plugin_skills.py -q -o 'addopts='

[alt-glitch]

Duplicate of #18901 (which is itself a duplicate of closed #18879/#17918). Root issue: #17914. All fix the same skill_view frontmatter-name resolution mismatch.

[teknium1]

This is implemented on current main now.

Automated hermes-sweeper review evidence:

• tools/skills_tool.py:1040 documents the now-supported frontmatter name: lookup for skill_view().
• tools/skills_tool.py:1052 implements the matching condition: fm.get("name") == name, then records the matching SKILL.md candidate.
• tests/tools/test_skills_tool.py:376 adds the regression test for a directory/frontmatter mismatch; tests/tools/test_skills_tool.py:391 verifies skill_view("real-skill-name") loads successfully.
• The implementation landed on main in 9caa12f4ecd29d4376914c059306cecd405b548a (fix(skills): resolve skill_view by frontmatter name when dir name differs).
• I also read @alt-glitch's duplicate note linking this PR to the same root frontmatter-name resolution issue.

Thanks for contributing the fix; the same behavior is already present on main.