Summary

PresetResolver._manifest_declared_template returns the first provides.templates entry matching a given (name, type) pair:

for tmpl in manifest.templates:
    if tmpl.get("name") == template_name and tmpl.get("type") == template_type:
        ...
        return tmpl, ...

So a preset.yml declaring two templates with the same (name, type) — e.g. two command/specify entries pointing at different files — had its second entry silently unreachable, while PresetManifest.templates still counted and exposed both. PresetManifest._validate never checked for this:

>>> PresetManifest(preset_yml_with_two_command_specify_entries)
# No error — accepted, both entries kept in .templates, but the resolver
# can only ever reach the first one.

Reject the duplicate at manifest-validation time instead, matching the sibling fix already applied to ExtensionManifest's provides.templates/provides.scripts (commit 11e3176, #4016): "The resolver returns the first entry matching a declared name, so a later duplicate ... was silently unreachable while still counted."

Presets use a (name, type) composite key rather than extensions' bare name, since the same name can legitimately recur across different template types (e.g. a template-type "specify" template and a command-type "specify" command) — the fix only rejects a duplicate within the exact same (name, type) pair.

Test plan

• Added test_duplicate_template_name_and_type_raises_validation_error and test_same_name_different_type_templates_allowed to tests/test_presets.py
• Verified the duplicate-rejection test fails without the fix (DID NOT RAISE) and passes with it; verified the same-name-different-type test passes both before and after (no false positive)
• pytest tests/test_presets.py — 602 passed, 8 pre-existing failures unrelated to this change (symlink-elevation tests that require admin rights on Windows, per this repo's documented Windows test-environment gaps), 2 skipped
• ruff check on both changed files — clean

🤖 Generated with Claude Code