Fix alternate row colors going out of order

[w-ahmad]

Description

Alternate row colors could end up in the wrong order after scrolling back and forth or changing the items, so two rows of the same shade appeared next to each other.

There were two causes, both in TableView.cs:

• Recycled rows kept their old colors. A recycled row has no TableView while its content changes, so the existing alternate-color pass skipped it and it kept the shade of its previous index. Colors are now applied in PrepareContainerForItemOverride, right after TableView is set.
• Insert/remove did not refresh later rows. Adding or removing an item shifts the index of every row after it, but those containers are not prepared again, so their shades went stale. A new Items.VectorChanged handler refreshes realized rows on ItemInserted/ItemRemoved, and only when an alternate brush is set.

EnsureAlternateRowColors now coalesces its dispatched pass so a burst of changes enqueues it once. The fix does not depend on this, so it can be dropped if you prefer a smaller diff.

Related Issue

Fixes #440

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 📝 Documentation update
• ♻️ Refactor
• 🧪 Test
• 🔧 Chore / maintenance

Checklist

• This PR is not from my main branch
• Tested with WinUI target
• Tested with Uno Platform target
• Unit / integration tests added or updated
• Documentation updated to reflect changes
• Code follows the project's coding conventions

Screenshots / Recordings

N/A

Additional Notes

• Added tests/TableViewAlternateRowColorsTests.cs (5 UI tests): initial rows, scrolling back and forth, collection reset, removing/inserting items above visible rows, and clearing the alternate brushes.
• The remove/insert test failed on the unmodified code in 3 of 3 runs. The scrolling and reset tests passed on the old code in this environment, so the recycled-row part of the fix is covered by reasoning rather than a failing test.
• With the fix, the new tests passed in 4 of 4 runs and the full suite passed 371/371 in 4 runs. One earlier full-suite run aborted with "Unable to communicate with test host process" and did not recur.
• Only the WinUI target was built and run. The Uno targets are untested; the new handler uses Items.VectorChanged, which TableViewHeaderRow already uses on all platforms.