Empty ListBoxes with remove_all to avoid stale rows crashing GTK (#153)

[gnacho]

Closes #153.

Problem

The app dies intermittently with SIGSEGV inside GTK widget-tree code during sync. Two coredumps: gtk_widget_get_request_mode (~42s after launch) and gtk_widget_is_sensitive (mid-sync, 3h uptime). Same failure class as the crashes fixed in #102/#121 (live callbacks touching widgets that left the tree).

Root cause (verified against GTK 4.22 source)

src/ui/conflict_resolver.rs rebuilt three GtkListBoxes by looping while let Some(child) = list.first_child() { child.unparent(); } (reload_deletions, reload_conflicts, rebuild_recent). In GTK4, gtk_widget_unparent does NOT clear the box's internal children sequence (only gtk_list_box_remove does), leaving ghost rows that, when freed, produce the exact asserts in the issue (insert_after with an invalid previous_sibling, G_IS_OBJECT failure) and the SEGV in gtk_widget_is_sensitive/gtk_widget_get_request_mode. The Recent tab rebuilds on a 2s poll whenever the activity log changes, i.e. during a sync - matching the intermittency.

Fix

src/ui/conflict_resolver.rs: replace the unparent loop with list.remove_all() in the three functions (the pattern already used at settings.rs:1865; gtk_list_box_remove_all exists since GTK 4.12, we build against v4_22).

Testing

New regression test rebuild_recent_replaces_the_rows_cleanly: rebuild with N rows, rebuild again with 1, assert only the new row remains (would fail with the unparent loop due to ghost children). Gate: clippy clean, fmt applied, tests green. No coredumps were recoverable today (the two in the issue remain the evidence); the fix targets the one identified stale-children vector that matches all observed asserts.