Summary

• Fixes a bug where enabling decomposeExternalServiceRegistrationBeta caused all .yaml files to be inferred as ExternalServiceRegistration, regardless of their directory location
• Adds strictDirectoryName: true to the yaml child type in the ESR preset
• Refines the suffix-based type resolution guard to only reject types when the file is NOT in the expected directory (previously it unconditionally rejected all strictDirectoryName types from suffix matching)

Work Item

@W-20424423@: Every *.yml file is now inferred as External Service Registration after enabling metadata decomposition

forcedotcom/cli#3463

Root Cause

The ESR preset registers yaml in the global suffixes map. During type resolution "attempt 3" (file extension → suffix lookup), any .yaml file would match. The existing guard (strictDirectoryName === true → reject) couldn't help because the yaml child type didn't have that flag set.

Fix

1. Set strictDirectoryName: true on the yaml child type
2. Change the guard from unconditional rejection to directory-aware rejection: only reject when fsPath does NOT contain the type's directoryName

Proof of Work

• Tests: 30193 passing (2 pre-existing failures unrelated to this change)
• Lint: clean (0 errors, 8 pre-existing warnings)
• Type check: clean
• New tests verify both the fix (yaml outside ESR dir → error) and non-regression (yaml inside ESR dir → resolves correctly)

Test plan

• sf project deploy start with decomposeExternalServiceRegistrationBeta enabled and a .yaml file in a non-ESR directory should not produce ConversionError
• ESR decomposition still works: .yaml files in externalServiceRegistrations/ are resolved and deployed correctly
• Existing snapshot tests pass (mdapi ↔ source round-trip for ESR)