Feature/Browser Notifications

[Rotto84]

Add browser notifications for download completion/failure

Summary

Implements the EnableNotifications option that already existed in the store/options UI but was previously non-functional (the checkbox was commented out with the note "Currently does nothing, so let's not show it"). Users can now opt in to a browser notification whenever a queued download finishes successfully or fails.

What changed

Completion detection (src/Client.ts)

• On each refresh, diffs the current queue's item IDs against the previous refresh's IDs to detect items that left the queue.
• Looks up each finished item in the downloader's history to determine success/failure, then dispatches to new addCompletionListener/removeCompletionListener subscribers.
• Skips the very first refresh (and refreshes right after switching downloaders) to avoid false notifications for items that were already finished before the extension started watching.
• Defaults to "success" if a finished item has no matching history entry, so a downloader hiccup doesn't produce false failure alerts.

History API implementation (src/downloader/SABnzbd.ts, src/downloader/NZBGet.ts)

• Both getHistory() methods were previously stubs returning []. Implemented real calls: SABnzbd's mode=history, NZBGet's history JSON-RPC method.
• Normalized both downloaders' status vocabularies to a consistent 'Completed' / 'Failed' string.
• Added an optional message field to NZBQueueItem (src/downloader/index.ts) to carry the failure reason:
  • SABnzbd: passes through its own fail_message field directly.
  • NZBGet: maps its combined status codes (e.g. FAILURE/PAR, WARNING/DAMAGED) to readable text via a small lookup table, with a generic fallback for unmapped codes.

Notification UI (src/entrypoints/background.ts)

• Subscribes to completion events, checks the EnableNotifications setting, and calls browser.notifications.create() with the extension's existing green/red icons.
• Failure reason (when available) is shown as the notification's contextMessage (the dimmer second line).
• Clicking a notification opens the downloader's web UI and clears the notification.

Options UI (src/entrypoints/options/Options.tsx)

• Re-enabled the previously commented-out "Enable Notifications" checkbox.

Testing

Added 15 unit tests, none requiring a live SABnzbd/NZBGet server:

• src/__tests__/Client.test.ts (8 tests) — queue-diffing/completion-detection logic, listener add/remove, multi-item completions, failure reason pass-through.
• src/downloader/__tests__/SABnzbd.history.test.ts (3 tests) — getHistory() parsing incl. fail_message.
• src/downloader/__tests__/NZBGet.history.test.ts (4 tests) — getHistory() parsing incl. status-code-to-reason mapping.

All 15 pass. tsc --noEmit and wxt build are clean. Manually tested end-to-end in Chrome with a live downloader — success and failure notifications both fire correctly and show the expected icon/title/reason.

Known limitations / follow-ups

• The getHistory() field mappings are based on SABnzbd's and NZBGet's documented API shapes; if either project changes field names in a future version, this may need adjustment.
• NZBGet's failure-reason lookup table (NZBGET_STATUS_REASONS) covers the most common codes (par, unpack, disk space, password, etc.) but not the full list NZBGet can emit — unmapped codes fall back to a readable but generic label rather than being dropped.
• The background script still polls via setInterval (pre-existing, not introduced by this PR) rather than chrome.alarms. Under Manifest V3, service workers can be evicted after ~30s idle, which can interrupt polling and reset in-memory completion tracking. There's an existing // TODO: Switch to alarms comment in Client.ts — worth addressing in a follow-up PR since it affects notification reliability, not just this feature.