Fix ListViewGroup ownership validation in Add and Insert

[abineshPalanisamy]

Fixes #4001

Proposed changes

• Add validation in ListViewGroupCollection.Add(ListViewGroup group) to prevent adding a ListViewGroup that already belongs to another ListView.
• Add validation in ListViewGroupCollection.Insert(int index, ListViewGroup group) to prevent inserting a ListViewGroup that already belongs to another ListView.
• Reuse the existing SR.OnlyOneControl resource string for the exception message.
• Throw ArgumentException when the ListViewGroup argument is already associated with a different ListView.
• Preserve existing behavior when the group is already present in the same collection.
• Preserve valid move scenarios where the group is removed or cleared from one ListView before being added to another.

Root cause

• ListViewGroup is expected to belong to only one ListView.
• ListViewGroup.ListView stores the owning ListView.
• Previously, ListViewGroupCollection.Add and Insert did not validate whether the group already belonged to another ListView.
• Because of this, the same ListViewGroup instance could be added to multiple ListViewGroupCollection instances.
• When the group was added to another ListView, group.ListView was overwritten with the latest ListView.
• This caused an inconsistent state where:
  • both ListView controls contained the same group in their Groups collection,
  • but group.ListView pointed only to the last ListView.

Customer Impact

• Prevents a ListViewGroup from being shared across multiple ListView controls.
• Avoids inconsistent internal state between ListViewGroupCollection and ListViewGroup.ListView.
• Prevents unexpected behavior when a group is reused incorrectly across different ListView controls.

Regression?

• No

Risk

• Low.
• The change is limited to ListViewGroupCollection.Add and ListViewGroupCollection.Insert.
• Existing same-collection behavior is preserved.
• Existing AddRange, IList.Add, and IList.Insert behavior is covered because these paths delegate to Add or Insert.
• Valid move scenarios continue to work when the group is first removed or cleared from the original ListView.
• No UI rendering behavior is changed.

Screenshots

Before

ListViewGroupCollection_Before_fix.mp4

After

ListViewGroupCollection_After_fix.mp4

Test methodology

• Reproduced the issue by adding the same ListViewGroup instance to two different ListView controls.
• Verified that before the fix:
  • the same group could exist in both ListViewGroupCollection instances,
  • group.ListView pointed only to the last ListView,
  • this created inconsistent ownership state.
• Verified that after the fix:
  • ListViewGroupCollection.Add throws ArgumentException when the group already belongs to another ListView.
  • ListViewGroupCollection.Insert throws ArgumentException when the group already belongs to another ListView.
• Verified delegated add paths:
  • IList.Add throws ArgumentException.
  • IList.Insert throws ArgumentException.
  • AddRange(ListViewGroup[]) throws ArgumentException.
• Verified regression scenarios:
  • Removing a group from one ListView and adding it to another works correctly.
  • Clearing groups from one ListView and adding the group to another works correctly.
• Added unit test coverage for the invalid cross-ListView ownership scenarios.
• Added regression test coverage for valid group move scenarios.

Accessibility testing

Test environment(s)

• 11.0.100-preview.3.26170.106

Microsoft Reviewers: Open in CodeFlow