Surface save failures in the UI

[dantheuber]

This branch assembles the listed issues for review.

Issues in this consist

• Surface clip and settings save failures in the UI #169 Surface clip and settings save failures in the UI

Closes #169

What & why

Debounced clip and settings saves that failed were only ever logged to the devtools console, so an unwritable store looked healthy until the app was relaunched. This surfaces those failures in the window itself: a toast on the transition into a failing state, plus a persistent banner for as long as the failure lasts.

Changes

• useClipsStorage now reports saveError alongside the existing loadError, tracking clip and settings save failures independently so one succeeding can't mask the other failing.
• The clips provider toasts "Clips could not be saved" (with the reason) on the transition into a failing state, gated by a ref so repeated failures from the debounced retry don't spam duplicate toasts; the gate resets once a save lands so a later failure is announced again.
• Clips.tsx renders the failure via a new StorageBanner component that makes the precedence explicit: an unreadable history banner wins over a refused-save banner, since the load-failure path also pauses saving. LoadFailedBanner and SaveFailedBanner share one StorageFailedBanner shell (title, lines, reason).
• README updated to document the new save-failure banner and toast.
• Version bumped to 2.4.0 (minor) — new user-facing capability, no breaking changes.

Review notes

• Nothing is disabled and no clips are dropped on a save failure; the in-memory list remains the source of truth and the next successful save clears the reported error.
• Worth double-checking the toast de-dupe ref logic in the provider and the banner precedence rule in Clips.tsx.
• Tests added for the storage hook, provider, and list component; full suite is green on this branch.

[github-actions]

📊 Coverage Report

Metric	Coverage
Statements	94.01%
Branches	93.56%
Functions	94.45%
Lines	94.28%

[github-actions]

🧪 E2E Test Results

✅ 38 passed, 0 failed, 0 skipped

Test Suite	Result
Analytics consent	✅
App Launch	✅
Clipboard	✅
Context Menu	✅
Image Clipboard	✅
Quick Clips	✅
Quick look	✅
Quick look — clipboard writes	✅
Quick look — rendered html	✅
Settings window	✅
Theme	✅
Settings — Tools tab	✅
Quick look — pattern scanning	✅
Quick look — clip templates	✅

[cb-jeeves]

This adds a save-failure path to useClipsStorage and a SaveFailedBanner plus toast in the clips window, with the banner choice pulled into its own StorageBanner component. The UI work is sound, but the feature does not fire in the shipped app: the main-process save wrappers swallow their errors and resolve false, so the renderer's catch never runs. That is the one blocking item. The other two are worth a look while you are in these files.

All four lenses ran this round.

The submit pass ran on claude-opus-5 after its primary model failed.

The correctness pass ran on claude-opus-5 after its primary model failed; maintainability pass ran on claude-opus-5 after its primary model failed; ux-dx pass ran on claude-opus-5 after its primary model failed.

[cb-jeeves]

Responded to review round 1, pushed 5eca56d:

• Addressed main-process save wrappers swallowing errors: saveClips and saveSettings in storage-integration.ts now log and rethrow, so the IPC handlers reject and the renderer catch runs with the real reason. errorText strips the "Error invoking remote method" wrapper Electron adds. Tests cover the wrapper rejecting and the hook receiving the Electron-shaped rejection.
• Addressed settings failure showing clip-loss copy: saveError carries its source, the list shows settings-specific lines for a refused clip limit, and the toast title follows the source.
• Addressed ref mirrored into state: one useState value with a functional update, saveError derived with useMemo.

[cb-jeeves]

The refused-save path now rejects through to the renderer and the banner names the file, which closes the blocking item from round 1. No further findings.

The submit pass ran on claude-opus-5 after its primary model failed.

The correctness pass ran on claude-opus-5 after its primary model failed; maintainability pass ran on claude-opus-5 after its primary model failed; ux-dx pass ran on claude-opus-5 after its primary model failed.