[resource-manager] resolveArmResources returns resources outside the selected version projection

[ArcturusZhang]

Description

resolveArmResources can return resources from the full/unprojected TypeSpec program that are not part of the SDK-selected API surface. This produces resource detection mismatches when versioned resources are added and removed across API versions.

This was found while comparing the Azure SDK for .NET management emitter's legacy resource detection output with resolveArmResources output.

Real case: NetApp

Spec location used by the .NET SDK generation:

# azure-sdk-for-net/sdk/netapp/Azure.ResourceManager.NetApp/tsp-location.yaml
directory: specification/netapp/resource-manager/Microsoft.NetApp/NetApp
commit: 048c7441c898e3067b00732016f853020ae7df5b
repo: Azure/azure-rest-api-specs

In the generated schema comparison:

legacy resource detection:       17 resources, 9 non-resource methods
resolveArmResources detection:   26 resources, 9 non-resource methods

The 9 extra resolveArmResources resources are:

• Microsoft.NetApp/activeDirectoryConfigs
• Microsoft.NetApp/elasticAccounts
• Microsoft.NetApp/elasticAccounts/elasticBackupPolicies
• Microsoft.NetApp/elasticAccounts/elasticBackupVaults
• Microsoft.NetApp/elasticAccounts/elasticBackupVaults/elasticBackups
• Microsoft.NetApp/elasticAccounts/elasticCapacityPools
• Microsoft.NetApp/elasticAccounts/elasticCapacityPools/elasticVolumes
• Microsoft.NetApp/elasticAccounts/elasticCapacityPools/elasticVolumes/elasticSnapshots
• Microsoft.NetApp/elasticAccounts/elasticSnapshotPolicies

These resources are decorated with alternating version ranges, for example:

@added(Versions.v2025_12_15_preview)
@removed(Versions.v2026_01_01)
@added(Versions.v2026_01_15_preview)
@removed(Versions.v2026_03_01)
@added(Versions.v2026_03_15_preview)
@removed(Versions.v2026_04_01)
@added(Versions.v2026_04_15_preview)
model ElasticAccount is TrackedResource<ElasticAccountProperties> { ... }

None of the extra resources' methods are present in the SDK method map used by the legacy/TCGC path, and their resolved apiVersions in the converted resolveArmResources schema are empty. That strongly suggests resolveArmResources is seeing resources from the unprojected/full program rather than the same version-projected API surface used by SDK generation.

Expected behavior

resolveArmResources should provide output aligned with the selected provider/version projection used by SDK generation, or expose explicit provider/version dimensions so emitters can select the relevant result.

For NetApp, resources that are not part of the SDK-selected API surface should not appear as extra resources in the result for that projection.

Actual behavior

resolveArmResources returns extra resources from versioned ranges that are not present in the SDK method map and have no resolved API versions in the converted schema.

This causes the resolver output to diverge from the actual generated SDK surface.

Relationship to design proposal

This appears related to the version-aware resolveArmResources design work in #4793. The proposed provider/version dimensions or projection-aware filtering should address this class of mismatch.