ListBox and TreeView targeted-repaint tests drain deterministically

The Studio test suite's targeted-repaint coverage for ListBox.RefreshRow(s) and TreeView.RefreshNode(s) did not always wait for every pending repaint before asserting. Under full-suite scheduling, a late repaint callback could land after the tests' drain step returned, causing a row or node that was not requested to be counted as repainted. The repaint-count assertions were correct; the test harness was not always quiescent.

The shared drain/quiescence logic used by both test families is being corrected so that, before resetting or asserting repaint counts, the harness deterministically waits until both the Avalonia UI dispatcher and the VM callback queue are fully settled. Targeted-repaint assertions are unchanged.