fix(storage): in-memory fallback when browser storage rejects writes (Safari private mode) (#613)

[jakespepe]

Summary

In Safari private browsing, localStorage.setItem and sessionStorage.setItem throw (QuotaExceededError) even for tiny writes. The same happens when storage is full or blocked by site settings. src/lib/storage.ts caught the error but threw the value away, so things like the stored wallet address, network, and the auth token in sessionStorage silently disappeared. The next get returned null.

Fix

In src/lib/storage.ts:

• Added an in-memory fallback map for each storage area (memoryLocal, memorySession).
• Writes (set, setJSON, setSession): if browser storage throws, the value goes into the matching map instead of being lost. A successful write clears any copy in memory, so browser storage stays the source of truth whenever it works.
• Reads (get, getJSON, getSession): if browser storage has no value or throws (Safari can raise SecurityError on reads too), the value comes from memory.
• Removes (remove, removeSession): clear both memory and browser storage.
• The API is unchanged:
  • set and setSession still return false when the value wasn't saved to browser storage, so the existing tests and any callers checking the result behave as before.
  • The existing one-time SecurityError warning is kept.
  • Quota errors are still not logged.

Why memory rather than falling back to sessionStorage: in Safari private mode sessionStorage has the same write restriction, so memory is the only fallback that always works. The values live only as long as the page, which matches what private browsing should do anyway.

This way nothing has to "detect private mode". Browser-sniffing is fragile, and the fallback only kicks in when a write actually fails.

Tests

Added to src/__tests__/storage.test.ts:

• A failed localStorage write is still readable through get and getJSON, and remove clears it
• If both getItem and setItem throw SecurityError, the value is still readable from memory
• Once a later write succeeds, browser storage is used again and the memory copy doesn't stick around
• A failed sessionStorage write (such as the auth token) is still readable through getSession, and removeSession clears it

npx vitest run src/__tests__/storage.test.ts
 Tests  11 passed (11)          # with the old storage.ts: 4 failed | 7 passed

Full suite: 60 failed / 413 passed on this branch vs 61 failed / 408 passed on main. The failures that were already on main are unrelated, and this PR adds no new ones. tsc --noEmit reports no errors in storage.ts.
Closes #613
Closes #612
Closes #614
Closes #615

[drips-wave]

@jakespepe Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[netlify]

❌ Deploy Preview for boisterous-sunshine-dd4c4c failed.

Name	Link
🔨 Latest commit	6e05766
🔍 Latest deploy log	https://app.netlify.com/projects/boisterous-sunshine-dd4c4c/deploys/6ab513bd2074400008808508