fix: refresh the Trash view in place after restore or permanent delete

[StuartMeeks]

Closes #62.

The bug

The Trash list did not update when a snip was restored or permanently deleted — the removed card stayed on screen until the user navigated away from Trash and back.

Cause

SaveAndRefreshTrashAsync rebuilt the view by assigning a replacement TrashViewModel to CurrentContent. That works when the content type changes: the shell's ContentControl resolves a different DataTemplate via ShellContentTemplateSelector and rebuilds its visual tree. But a TrashViewModel → TrashViewModel swap keeps the same template, so the trash template's compiled bindings — ItemsSource="{x:Bind Snips}" and Visibility="{x:Bind IsEmpty, ...}", both one-time — keep pointing at the discarded view model's list.

That also explains the reported workaround exactly: navigating away swaps in a different content type, which forces the rebuild.

Fix

TrashViewModel now owns a persistent Snips collection that a new Load() repopulates in place, raising change notifications for the computed HasSnips / IsEmpty. The shell reuses the live instance when Trash is the current view:

if (CurrentContent is TrashViewModel trash)
{
    trash.Load(_document.Snips.Where(s => s.IsTrash));
}
else
{
    CurrentContent = BuildTrashViewModel();
}

The ItemsControl now sees INotifyCollectionChanged notifications from a collection instance that survives the refresh, so the list tracks the document regardless of binding mode.

This is the pattern HistoryViewModel already uses — the one content view that refreshes in place, and, tellingly, the only one whose template was already bound Mode=OneWay. Trash is now consistent with it.

The empty-state placeholder ("Trash is empty.") had the same root cause and additionally needed Mode=OneWay to appear once the last trashed snip goes — that is the "clearing the trash" half of the report.

I deliberately left the Home and CLI content paths alone: they assign replacement view models too, but their refresh is always driven by a flow that works today, and reworking them is out of scope for this fix.

Verification

• Three new shell tests (DeleteForever_refreshes_the_live_trash_view_in_place, Deleting_the_last_trashed_snip_announces_the_empty_state, RestoreSnip_refreshes_the_live_trash_view_in_place) — I confirmed all three fail against the old implementation and pass with the fix, so they genuinely guard the regression.
• New TrashViewModelTests covering Load ordering, collection-instance reuse, notifications and null rejection.
• 253 Core tests pass (was 245); full solution including the WinUI head builds clean, 0 warnings, on a Windows 11 host.

Needs your eyes: I can compile the WinUI head but not run it, so the on-screen behaviour is unverified — worth a quick manual check that restore, delete-permanently and emptying the last item all update the list live.

One question

There is no "empty trash" / "clear all" command anywhere in the codebase — RestoreSnip and DeleteForever are the only trash actions. I read the "clearing the trash" half of the issue as deleting the last remaining item, which this fixes. If you meant a bulk Empty trash button, that is a new feature rather than this bug — say the word and I will raise it separately.

🤖 Generated with Claude Code