fix(skills): ignore internal asset markdown during skill lookup

[westkite1201]

Summary

• fixes [Bug]: skill_view falsely reports collision when another skill has an asset file with the same name #35743
• keeps legacy flat <name>.md skill lookup while skipping markdown files inside another skill directory
• adds regression coverage for internal asset files named like real skills and for top-level legacy markdown skills

Testing

• uv run --with pytest-timeout pytest tests/tools/test_skills_tool.py -q
• uv run ruff check tools/skills_tool.py tests/tools/test_skills_tool.py
• python3 -m py_compile tools/skills_tool.py tests/tools/test_skills_tool.py && git diff --check
• python3 scripts/check-windows-footguns.py --diff origin/main

Notes

• Full repository test suite not run locally.

[liuhao1024]

Verified this fix is correct.

The bug: Strategy 3 in _find_skill_markdown (skills_tool.py:963) uses search_dir.rglob(f"{name}.md") to find legacy flat skill files. When a skill like popular-web-designs contains an asset file templates/notion.md, the rglob matches it as a "notion" skill candidate, causing a collision with the real notion skill's SKILL.md.

Fix validation: The new _is_inside_skill_dir helper correctly walks up from the found .md file toward the search root, checking for SKILL.md at each ancestor. If a SKILL.md is found before reaching the root, the file is inside a skill directory and is skipped. The ancestor == root check terminates the walk correctly — top-level .md files directly under the search root are not rejected.

Edge case: The function returns False when the walk reaches root without finding SKILL.md, which correctly preserves the legacy flat-file behavior for files at the top level of a skills directory.

[alt-glitch]

Same root cause as #35768 and #36895 — all three fix #35743 (skill lookup treating nested markdown assets inside other skill dirs as standalone legacy skills, causing false collisions). Consolidate to one.

[westkite1201]

Thanks for pointing this out. I missed #35768/#36895 during the duplicate check. Since #35768 predates this PR and covers the same root cause, I'll close this one to avoid splitting review. Appreciate the pointer.