Fix LastContractPropertiesMap overriding collection property type when element type changes

[Copilot]

The backcompat logic in ModelProvider.BuildProperties() unconditionally overrides a collection property's type to match the last contract when types differ. This was intended to preserve IReadOnlyList<T> → IList<T> wrapper changes, but it also overrides the type when the element type itself has legitimately changed (e.g., via @typeChangedFrom), discarding the intentional type change.

Fix

• ModelProvider.cs: Added an AreNamesEqual-based argument comparison guard so the override only fires when the element/value types match between old and new — i.e., only the collection wrapper changed. We use AreNamesEqual rather than SequenceEqual/Equals because the argument types may come from different sources (TypeProvider vs compiled assembly) but represent the same logical type. We compare all Arguments (not just ElementType) to cover both list element types and dictionary key/value types.

if (LastContractPropertiesMap.TryGetValue(outputProperty.Name,
        out CSharpType? lastContractPropertyType) &&
    !outputProperty.Type.Equals(lastContractPropertyType) &&
    outputProperty.Type.Arguments.Count == lastContractPropertyType.Arguments.Count &&
    outputProperty.Type.Arguments.Zip(lastContractPropertyType.Arguments).All(
        pair => pair.First.AreNamesEqual(pair.Second)))

• ModelProviderTests.cs: Added BackCompat_CollectionPropertyTypeNotOverriddenWhenElementTypeChanges — last contract has IList<IDictionary<string, BinaryData>>, new model produces IList<NewElementModel>, asserts the new element type is preserved.
• Test data: MockInputModel.cs simulating last contract with the old element types.

[JoshLove-msft]

I think it would be more straightforward to use ElementType, though I suppose that wouldn't account for dictionary keys. If we leave it like this we should probably add a comment.

[live1206]

@copilot could you help to add comment explaining this?

[Copilot]

Added a comment explaining the Arguments.SequenceEqual usage — it covers both list element types and dictionary key/value types, whereas ElementType alone wouldn't account for dictionary keys. See 1ee9866.

[live1206]

@copilot could you help to check the CI failures?

[Copilot]

@copilot could you help to check the CI failures?

The CI workflows show action_required (pending approval) with no jobs executed yet. However, I found an actual test failure locally: BackCompat_ReadOnlyCollectionEnumPropertiesAreRetained was failing because Arguments.SequenceEqual uses CSharpType.Equals which does full structural comparison — the ElementEnum from the current TypeProvider and from the compiled last contract assembly have different internal _type fields, so they don't match structurally even though they represent the same logical type.

Fixed in e5061a8 by replacing SequenceEqual with AreNamesEqual-based argument comparison, which correctly matches types across different sources by their fully-qualified names. All 29 BackCompat tests pass now.