Notification persistence: only release notifications should survive a reboot #401

What

Decide and implement a clear persistence policy for the notification bell: which notification
kinds should survive an app reboot/reload, and which should clear.

Current behavior

• Release notifications ("New release available"): persisted via localStorage
  (DISMISSED_UPDATE_KEY, static/js/catalog.js). Dismissal is stored per-version, so the card
  survives a reboot and only stops showing once the user dismisses that specific version.
• Failure notifications (import/playback/export/update-check-failed): persisted deliberately
  across reload via the desktop store (static/js/notifications.js, FAILURES_KEY). This is by
  design, not an oversight: issue [Bug]: A track that fails to load tells the user nothing #359 specifically made failures survive a reload, because before
  that fix a failure lived in a transient banner and dismissing or reloading lost the evidence a
  user needed to file a report.

The open question

Only release notifications should persist across reboot by default; everything else should clear.
Implementing that literally reintroduces the exact problem #359 fixed: a failure notification the
user hasn't looked at yet would vanish on the next app restart, and the evidence (traceback, stderr
tail) goes with it.

Before this gets implemented, decide: is that tradeoff intentional (accept losing #359's benefit in
exchange for a tidier bell after restart), or is there a narrower behavior that gets the tidiness
without the regression, e.g. auto-clearing a failure only once its underlying job/action is
confirmed resolved, while still surviving a simple reload in the meantime?

Related

• [Bug]: A track that fails to load tells the user nothing #359 (why failure notifications persist in the first place)
• [Bug]: Several issues with my portable package #399 (where this question came up, but unrelated to that issue's portability scope)