fix(gui): erase virtual-list rows freed by a shrink

[got3nks]

When rows are removed from a virtual list (clients, downloads, shared files), the leftover rows below the new count stayed painted on screen — stale, non-clickable rows that only cleared on a full repaint (e.g. switching panels).

Root cause

CMuleVirtualListCtrl::RefreshFromRow() clamped its repaint range to the new (smaller) item count after an erase, so the strip below the last surviving row was never invalidated. OnPaint only clears the update region, so those pixels kept their old content.

Fix

Repaint from the first shifted row down to the bottom of the client area instead of stopping at the last item, via a new wxGenericListCtrl::RefreshAfter() forwarder to the existing wxListMainWindow::RefreshAfter(). OnPaint clears the whole update region first, so the freed tail is redrawn as background.

Because the fix lives in the shared RefreshFromRow() path, one change covers all three CMuleVirtualListCtrl lists. It surfaced on the shared-file peers list in #399 (client rows lingering after peers disconnect), but the same repaint gap existed on the download and shared-files lists.

Testing

• amulegui peers list: disconnecting clients now clear immediately instead of leaving stale rows until a panel switch.
• @ghysler is verifying the fixed x64 build, the configuration where it was originally reported.