Let users review and suppress recurring crash types

[ferlemes]

Motivation

Crash notifications currently hand a crash directly to the default AI agent when clicked. That is useful for a new failure, but it becomes noisy when the same known crash keeps recurring and the user has already decided not to investigate or fix it.

The case that motivated this change was a crash repeatedly triggered while Claude was performing an operation. It was not a crash I planned to address, but each occurrence still offered the same direct diagnosis path. Muting the whole program would be too broad because a different crash from that executable could still be actionable.

What changed

• Open a local crash review before launching the AI diagnosis.
• Retain a private summary and recurrence count for each crash type.
• Define a crash type from the executable, signal, and command line, hashed as a SHA-256 signature.
• Let users dismiss one occurrence, snooze a crash type, ignore that exact crash type permanently, or mute all crashes from the program.
• Keep counting ignored recurrences without showing another notification.
• Deduplicate notifications by crash signature rather than only by program name.
• Document the review and ignore flows and cover them in the crash capture tests.

This keeps unrelated failures visible: ignoring one known probe does not suppress every crash from the same executable.

Testing

• bash test/shell.d/crash-capture-test.sh passes.
• Built and installed the development package locally, generated a real SIGSEGV core dump from /usr/bin/sleep, and verified that the notification opened the new review flow.
• ./test/all was also run. The crash coverage passes; the suite reports four failures outside the touched area: launch-about-test.sh, network-qr-test.sh, plugin-add-test.sh (GPG state is read-only in the sandbox), and snapper-test.sh (the sibling omarchy-iso checkout is unavailable).

[lemes-eulen]

Crash review screen: