EffectiveViewportChanged using Scroll Ports from other windows

### Describe the bug

It seems that when the EffectiveViewportChangedArgs are calculated, they are taking into account scroll ports from other windows.
This causes all of the args to be incorrectly constrained as if the windows were overlapping each-other.

Sample repro available at https://github.com/will-velazquez/effective-viewport-bug

### Steps to reproduce the bug

1. Create a window with a noop EffectiveViewportChanged handler on any of its element
2. Create a second window with an EffectiveViewportChanged handler on one of its elements
3. Resize the original window to be smaller than the second window
4. EffectiveViewPortChanged handler is called on the second window, and the values given are wrong

### Expected behavior

Each window should track its scroll ports separately

### Screenshots

From running https://github.com/will-velazquez/effective-viewport-bug

https://github.com/user-attachments/assets/2f7f4b92-273b-4343-a376-f1e27ddea3ef

### NuGet package version

WinUI 3 - Windows App SDK 1.6.1: 1.6.240923002

### Windows version

Windows 11 (22H2): Build 22621

### Additional context

_No response_

Start with the linked effective-viewport-bug reproduction and trace EffectiveViewportChangedArgs, focusing on how scroll ports are collected across the two windows. Done means each window tracks only its own scroll ports and the second window reports correct values after the first is resized.

Written by the indexing model from the issue text.