Migration: Move from localStorage to browser/chrome.storage (with sync support)

[prem-k-r]

Description

We plan to migrate MYNT from localStorage to the browser Storage API (browser.storage.local / chrome.storage.sync) for better reliability and optional cross-device sync support on Chrome.

This issue tracks the migration plan and key considerations.

---

Proposed changes

• Use browser.storage.local / chrome.storage.sync instead of localStorage
• Keep using localStorage for quotes and IndexedDB for wallpapers due to Chrome sync storage limits

---

Things to take care of

1. Migration of existing users’ data

• Detect existing settings stored in localStorage
• Migrate them to the new Storage API
• Clear localStorage after successful migration
• Ensure no user data loss during update

---

2. Chrome vs Firefox handling

• Use chrome.storage.sync on Chrome (if available)
• Fallback to browser/chrome.storage.local on Firefox
• Firefox will remain local-only (no sync support)

---

3. Chrome storage.sync limits

• Respect Chrome sync quotas
• Sync only lightweight settings
• Continue storing wallpapers and quotes locally

---

4. Offline support

• Extension must work fully offline
• storage.sync writes locally first
• Sync happens later when the browser is online
• Code must not assume internet availability

---

5. Async handling

• chrome.storage.* APIs are asynchronous
• UI must wait for settings before rendering
• Avoid race conditions on startup

---

6. Centralized storage wrapper

Use a single wrapper everywhere in the codebase, for example:

const Storage = {
    get: (keys) => {
        if (chrome.storage?.sync) return chrome.storage.sync.get(keys);
        return chrome.storage.local.get(keys);
    },
    set: (obj) => {
        if (chrome.storage?.sync) return chrome.storage.sync.set(obj);
        return chrome.storage.local.set(obj);
    }
};

---

7. Initial sync timing

• Chrome sync is not instant on fresh installs
• Load default UI first
• Update UI when synced settings arrive using storage.onChanged

---

8. Backup and restore compatibility

• Old backups (localStorage-based) must continue to work
• New backups should be created from the Storage API
• Restore logic must support both formats

---

9. Required permission

Add to manifest.json:

"permissions": ["storage"]

---

10. Avoid double-saving

• Do not save the same data in:

  • localStorage
  • chrome.storage.local
  • chrome.storage.sync

• After migration, maintain a single source of truth

Note

AI generated description (Errors are there)

[coderabbitai]

Coding Plan

Approach

Ticket Summary

Migrate MYNT from localStorage to browser Storage API (chrome.storage.sync/local) for improved reliability and optional cross-device sync on Chrome, while maintaining backward compatibility with existing user data and ensuring seamless transition for all users.

Observations

Codebase Summary

MYNT is a browser extension (Chrome Manifest v3 and Firefox Manifest v2) with 19 JavaScript files that currently use localStorage directly for storing 34+ unique keys including user preferences, cached data, and UI states. The extension uses IndexedDB for wallpaper storage (not localStorage as originally assumed) and localStorage for multilingual quotes. The initialization flow begins with preload.js running synchronously to set up the loading screen, followed by deferred scripts using DOMContentLoaded listeners. The current backup-restore.js already handles both localStorage and IndexedDB backups in a unified JSON structure.

Assumptions

Assumption 1: Data classification for sync vs local storage

Options Considered:

• Store all settings in sync storage and all data in local storage
• Use a hybrid approach based on data size and user benefit
• Create an explicit whitelist/blacklist configuration

Chosen Option: Hybrid approach with size-aware routing

Rationale: Store lightweight UI preferences and settings (theme, clock type, language, display toggles) in chrome.storage.sync (limited to 100KB total, 8KB per item), while larger data (todo lists, weather cache, AI tools settings) goes to chrome.storage.local. Keep quotes in localStorage and wallpapers in IndexedDB (no changes). This provides the best user experience by syncing preferences users care about across devices while respecting quota limits.

Assumption 2: Migration timing and strategy

Options Considered:

• One-time migration in background script on extension update
• Lazy migration on-demand when each setting is accessed
• Preload migration before any scripts execute

Chosen Option: One-time migration in background script with preload fallback

Rationale: Use chrome.runtime.onInstalled to trigger automatic migration on extension updates (runs once per user). Additionally, implement a migration check in preload.js for users who somehow bypass the background migration. This ensures reliable data transfer while maintaining the existing synchronous initialization pattern during the transition period.

Assumption 3: Handling async storage in synchronous initialization flow

Options Considered:

• Make preload.js async with top-level await (requires module type)
• Use a synchronous localStorage fallback during transition
• Pre-cache storage values in a service worker/background script

Chosen Option: Make preload.js async with storage wrapper fallback

Rationale: Convert preload.js to an async module and use await for storage reads. During the migration period, the storage wrapper will check both Storage API and localStorage (reading Storage API first, falling back to localStorage) to ensure no user sees broken UI. Once migration completes, remove localStorage fallback. This approach aligns with modern extension development practices while maintaining backward compatibility.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Storage Infrastructure & Wrapper

Create the foundational storage abstraction layer that handles cross-browser compatibility and provides a unified API for all storage operations.

Task 1: Create centralized storage wrapper

Create a new storage utility module that abstracts chrome.storage.sync/local with browser compatibility

• Create scripts/storage-wrapper.js that exports get(), set(), remove(), clear() methods
• Implement browser detection using existing browser-utils.js constants (isFirefox, isChrome)
• Use chrome.storage.sync for Chrome when available, fall back to chrome.storage.local on Firefox or when sync unavailable
• Handle offline scenarios automatically as "Chrome stores the data locally when the browser is offline and resumes syncing when it's back online"
• Return Promises for all operations to maintain async pattern consistency

Task 2: Define storage routing configuration

Create a configuration file that maps storage keys to appropriate storage backends

• Create scripts/storage-config.js defining which keys use sync storage vs local storage
• Classify lightweight settings (preferredTheme, clocktype, selectedLanguage, hideClockVisible, etc.) for chrome.storage.sync
• Classify larger data (todoList, weatherParsedData, aiToolsSettings, shortcut data) for chrome.storage.local
• Classify excluded data (quotes_* keys for localStorage, wallpaper data for IndexedDB)
• Export a function that determines storage backend for any given key based on configuration

Task 3: Update manifest files

Add storage permission to both Chrome and Firefox manifests

• Add "storage" permission to manifest.json permissions array
• Add "storage" permission to manifest(firefox).json permissions array
• For Firefox manifest, ensure browser_specific_settings includes extension ID (required for storage.sync per Mozilla documentation)

🤖 Prompt for AI agents

Phase 1: Build the storage abstraction layer and configuration infrastructure.

Create scripts/storage-wrapper.js:
- Export async get(), set(), remove(), clear() methods that return Promises
- Detect browser using browser-utils.js (isFirefox, isChrome)
- For Chrome: use chrome.storage.sync, handle offline automatically
- For Firefox: use chrome.storage.local (sync not available)
- All methods should accept key(s) and return/handle values appropriately

Create scripts/storage-config.js:
- Define which keys use sync storage (lightweight settings like preferredTheme,
clocktype, selectedLanguage, hideClockVisible)
- Define which keys use local storage (larger data like todoList,
weatherParsedData, aiToolsSettings, shortcut data)
- Define excluded keys (quotes_* for localStorage, wallpaper data for IndexedDB)
- Export a function that returns the storage backend for any given key

Update manifest.json and manifest(firefox).json:
- Add "storage" to permissions array in both files
- Ensure Firefox manifest has browser_specific_settings.id defined

Phase 2: Migration Infrastructure

Implement one-time migration logic to transfer existing localStorage data to the Storage API without data loss.

Task 1: Create background script for Chrome

Implement migration logic in background service worker for Manifest v3

• Create scripts/background.js (currently empty) with chrome.runtime.onInstalled listener
• Implement migration function that reads all localStorage keys (excluding quotes_* and wallpaper-related keys)
• For each key, determine target storage (sync vs local) using storage-config.js
• Copy data to appropriate Storage API backend using storage-wrapper.js
• Set a migration flag (e.g., "migrationCompleted": true) in chrome.storage.local to prevent re-migration
• Handle errors gracefully with fallback to localStorage if migration fails partially
• Add "background" service worker configuration to manifest.json

Task 2: Update Firefox background script

Adapt migration logic for Firefox Manifest v2 background page

• Use the same migration function from Task 2.1 but adapt for browser.runtime API instead of chrome.runtime
• Reference the existing scripts/background.js from manifest(firefox).json (already configured)
• Use browser.storage.local instead of chrome.storage for migration flag storage
• Ensure Firefox-specific handling for persistent background page vs service worker

Task 3: Add migration fallback in preload

Implement migration check at startup for users who bypass background script migration

• Update scripts/preload.js to check for migration completion flag from Storage API
• If not migrated, trigger synchronous-like migration before proceeding with initialization
• Read LoadingScreenColor from Storage API first, fall back to localStorage during transition
• This ensures users see correct UI even if background migration hasn't completed yet

🤖 Prompt for AI agents

Phase 2: Implement one-time migration from localStorage to Storage API.

Create scripts/background.js for Chrome (Manifest v3):
- Add chrome.runtime.onInstalled listener
- In migration function: iterate all localStorage keys except quotes_* and
wallpaper keys
- Use storage-config.js to determine if each key goes to sync or local storage
- Use storage-wrapper.js to write data to appropriate backend
- Set migrationCompleted flag in chrome.storage.local
- Handle errors gracefully
- Add background service worker to manifest.json

Adapt for Firefox (Manifest v2):
- Use browser.runtime API instead of chrome.runtime
- Use browser.storage.local for migration flag
- Handle persistent background page differences
- Reference from manifest(firefox).json

Update scripts/preload.js:
- Check for migrationCompleted flag from Storage API on startup
- If not migrated, trigger migration
- Read LoadingScreenColor from Storage API first, fall back to localStorage if
not found
- Ensure UI displays correctly during migration

Phase 3: Core Storage API Migration

Replace all direct localStorage calls with the storage wrapper throughout the codebase.

Task 1: Convert preload.js to async initialization

Make preload.js work with async Storage API while maintaining required functionality

• Convert preload.js to async function or ES module with top-level await
• Replace localStorage.getItem('LoadingScreenColor') with storage-wrapper get() call
• Use await to retrieve value before setting CSS variable
• Handle Promise rejection with default fallback value

Task 2: Update script.js initialization

Convert main script initialization to use async storage reads

• Wrap DOMContentLoaded listener content in async function
• Replace localStorage.getItem("hideTips") and localStorage.getItem(STORAGE_KEY) with storage-wrapper calls
• Use await pattern for sequential storage reads
• Ensure all UI state applications happen after storage reads complete

Task 3: Migrate save-load-states.js or deprecate

Update or remove the largely unused save-load-states.js module

• If the module will be used going forward: update all six functions (saveCheckboxState, loadCheckboxState, saveDisplayStatus, loadDisplayStatus, saveActiveStatus, loadActiveStatus) to use storage-wrapper instead of localStorage
• Convert all functions to async and return Promises
• If the module remains unused: remove the file and document that storage-wrapper.js replaces it
• Update any remaining references in other files

Task 4: Migrate high-usage files

Update the files with most localStorage operations (weather.js, search.js, quotes.js, shortcuts.js)

• weather.js (13 setItem, 10 getItem): Replace all localStorage calls with storage-wrapper, classify weather data keys as local storage (cached data), keep API key in sync storage
• search.js (10 setItem, 8 getItem): Replace with storage-wrapper, classify search engine preferences as sync storage
• quotes.js (9 setItem, 7 getItem): Replace quotes_* key operations with direct localStorage access wrapped in try-catch (these stay in localStorage per requirements), update other preferences to use storage-wrapper
• shortcuts.js (7 setItem, 7 getItem, 5 removeItem): Replace with storage-wrapper, classify shortcut data as local storage due to size

Task 5: Migrate remaining files

Update all other files that use localStorage (15 remaining files)

• Identify all localStorage.getItem, localStorage.setItem, localStorage.removeItem, localStorage.clear calls across: ai-tools.js, bookmarks.js, clock.js, theme.js, tips.js, todo-list.js, wallpaper.js, and others
• Replace with storage-wrapper calls
• Add async/await patterns where needed
• Ensure each file uses appropriate storage backend based on storage-config.js routing

🤖 Prompt for AI agents

Phase 3: Replace all localStorage calls with storage-wrapper throughout the
codebase.

Convert scripts/preload.js:
- Make it async (ES module with top-level await)
- Replace localStorage.getItem('LoadingScreenColor') with await
storageWrapper.get('LoadingScreenColor')
- Add error handling with default fallback

Update scripts/script.js:
- Wrap DOMContentLoaded content in async function
- Replace localStorage.getItem calls with await storageWrapper.get() calls
- Ensure UI updates happen after storage reads complete

Handle scripts/save-load-states.js:
- Convert all functions to async and use storage-wrapper
- OR remove file if unused and document replacement

Migrate high-usage files:
- weather.js: Replace localStorage with storage-wrapper (weather data → local,
API key → sync)
- search.js: Replace localStorage with storage-wrapper (preferences → sync)
- quotes.js: Keep quotes_* in localStorage, migrate other preferences to
storage-wrapper
- shortcuts.js: Replace localStorage with storage-wrapper (data → local)

Migrate remaining files (ai-tools.js, bookmarks.js, clock.js, theme.js, tips.js,
todo-list.js, wallpaper.js, etc.):
- Replace all localStorage calls with storage-wrapper
- Add async/await as needed
- Follow storage-config.js routing

Phase 4: Backup & Restore Compatibility

Update backup and restore functionality to work with Storage API while maintaining compatibility with old localStorage-based backups.

Task 1: Update backup functionality

Modify backup-restore.js to read from Storage API instead of localStorage

• Update backupData() function to read from chrome.storage.sync and chrome.storage.local
• Aggregate both sync and local storage into a unified object
• Merge localStorage data (quotes_*) and IndexedDB data (wallpapers) into backup structure
• Maintain existing backup format: { localStorage: {...}, indexedDB: {...} } for backward compatibility
• For new backups, store Storage API data under "localStorage" key and mark with metadata flag to indicate source

Task 2: Update restore functionality

Update restore logic to detect and handle both old localStorage and new Storage API backups

• Modify restoreData() to detect backup format (check for metadata flag)
• For old backups: restore "localStorage" object to localStorage first, then migrate to Storage API
• For new backups: restore "localStorage" object directly to chrome.storage.sync/local based on key classification
• Maintain IndexedDB restore logic unchanged
• Preserve quotes_* keys in localStorage regardless of backup format
• Clear localStorage after restore (except quotes_*) to prevent double-storage

🤖 Prompt for AI agents

Phase 4: Update backup and restore to work with Storage API while maintaining
backward compatibility.

Update backupData() in scripts/backup-restore.js:
- Read from chrome.storage.sync and chrome.storage.local instead of localStorage
- Aggregate sync and local storage into unified object
- Merge quotes_* from localStorage and wallpapers from IndexedDB
- Maintain format: { localStorage: {...}, indexedDB: {...} }
- Add metadata flag to indicate Storage API source

Update restoreData() in scripts/backup-restore.js:
- Detect backup format by checking metadata flag
- For old backups: restore to localStorage, then trigger migration to Storage
API
- For new backups: restore directly to chrome.storage.sync/local based on
storage-config.js
- Keep IndexedDB restore logic unchanged
- Always preserve quotes_* in localStorage
- Clear localStorage after restore (except quotes_*)

Phase 5: Storage Change Listeners & Sync Handling

Implement listeners to handle synced settings arriving after initial load and update UI accordingly.

Task 1: Add storage change listener infrastructure

Create listeners for chrome.storage.onChanged events

• Add chrome.storage.onChanged.addListener in storage-wrapper.js or dedicated listener module
• Filter changes by storage area (sync vs local) and key
• Emit custom events or callback notifications when relevant settings change
• Handle sync data arriving after initial load as Chrome stores locally and syncs when online

Task 2: Update UI modules to listen for storage changes

Connect UI components to respond to synced settings updates

• Update scripts/theme.js to listen for theme preference changes and apply updates
• Update scripts/clock.js to listen for clock type changes
• Update scripts/search.js to listen for search engine preference changes
• Add listeners for other UI preferences that might sync from other devices
• Ensure listeners don't cause race conditions with initial load

Task 3: Implement initial sync timing strategy

Handle the case where Chrome sync isn't instant on fresh installs

• Load default UI values first before Storage API reads complete (don't block rendering)
• Apply stored preferences as soon as Storage API get() resolves
• Apply synced preferences when storage.onChanged fires with newer data
• Use timestamps or version numbers to determine which settings are most recent
• Prevent UI flicker by batching updates where possible

🤖 Prompt for AI agents

Phase 5: Add listeners for synced settings and handle updates from other
devices.

Add storage change listeners:
- In storage-wrapper.js (or new listener module), add
chrome.storage.onChanged.addListener
- Filter by storage area (sync/local) and key
- Emit custom events or callbacks when relevant settings change
- Handle delayed sync when coming back online

Update UI modules to respond to storage changes:
- theme.js: Listen for theme preference changes and apply
- clock.js: Listen for clock type changes and update
- search.js: Listen for search engine changes and update
- Add listeners for other synced UI preferences
- Prevent race conditions with initial load

Implement sync timing strategy:
- Load default values first (don't block rendering)
- Apply stored preferences when Storage API get() resolves
- Apply synced preferences when storage.onChanged fires
- Use timestamps/versions to determine most recent
- Batch updates to prevent flicker

Phase 6: Cleanup & Validation

Remove temporary migration code, validate storage usage, and finalize the migration.

Task 1: Remove localStorage fallback reads

Clean up dual-storage patterns after migration is complete

• Remove localStorage fallback checks from storage-wrapper.js (keep only Storage API)
• Remove migration detection code from preload.js
• Keep quotes_* localStorage access intact (required per ticket)
• Keep wallpaper IndexedDB access intact (already not using localStorage)

Task 2: Add storage quota monitoring

Implement monitoring for chrome.storage.sync quota limits

• Add getBytesInUse() checks before large write operations to chrome.storage.sync
• Implement error handling for "QUOTA_BYTES quota exceeded" errors
• Respect the 100KB total and 8KB per item limits for sync storage
• Log warnings when approaching quota limits
• Provide fallback to chrome.storage.local if sync quota exceeded

Task 3: Testing and validation

Validate migration across different user scenarios

• Test fresh install flow (no existing data)
• Test existing user upgrade flow (localStorage → Storage API migration)
• Test backup and restore with old localStorage backups
• Test backup and restore with new Storage API backups
• Test offline functionality and sync behavior when coming back online
• Verify no data stored in both localStorage and Storage API (except quotes_*)
• Verify wallpapers remain in IndexedDB only

🤖 Prompt for AI agents

Phase 6: Clean up migration code, add quota monitoring, and validate the
implementation.

Remove localStorage fallbacks:
- Remove localStorage fallback reads from storage-wrapper.js (keep only Storage
API)
- Remove migration detection from preload.js
- Keep quotes_* in localStorage
- Keep wallpapers in IndexedDB

Add quota monitoring:
- Use chrome.storage.sync.getBytesInUse() before large writes
- Handle QUOTA_BYTES quota exceeded errors
- Respect 100KB total and 8KB per item limits
- Log warnings when approaching limits
- Fall back to chrome.storage.local if sync quota exceeded

Testing checklist:
- Fresh install (no data)
- Upgrade flow (localStorage → Storage API)
- Backup/restore with old backups
- Backup/restore with new backups
- Offline/online sync behavior
- No duplicate storage (except quotes_*)
- Wallpapers in IndexedDB only

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Phase 1: Build the storage abstraction layer and configuration infrastructure.

Create scripts/storage-wrapper.js:
- Export async get(), set(), remove(), clear() methods that return Promises
- Detect browser using browser-utils.js (isFirefox, isChrome)
- For Chrome: use chrome.storage.sync, handle offline automatically
- For Firefox: use chrome.storage.local (sync not available)
- All methods should accept key(s) and return/handle values appropriately

Create scripts/storage-config.js:
- Define which keys use sync storage (lightweight settings like preferredTheme,
clocktype, selectedLanguage, hideClockVisible)
- Define which keys use local storage (larger data like todoList,
weatherParsedData, aiToolsSettings, shortcut data)
- Define excluded keys (quotes_* for localStorage, wallpaper data for IndexedDB)
- Export a function that returns the storage backend for any given key

Update manifest.json and manifest(firefox).json:
- Add "storage" to permissions array in both files
- Ensure Firefox manifest has browser_specific_settings.id defined
===============================================================================

Task: 2

Phase 2: Implement one-time migration from localStorage to Storage API.

Create scripts/background.js for Chrome (Manifest v3):
- Add chrome.runtime.onInstalled listener
- In migration function: iterate all localStorage keys except quotes_* and
wallpaper keys
- Use storage-config.js to determine if each key goes to sync or local storage
- Use storage-wrapper.js to write data to appropriate backend
- Set migrationCompleted flag in chrome.storage.local
- Handle errors gracefully
- Add background service worker to manifest.json

Adapt for Firefox (Manifest v2):
- Use browser.runtime API instead of chrome.runtime
- Use browser.storage.local for migration flag
- Handle persistent background page differences
- Reference from manifest(firefox).json

Update scripts/preload.js:
- Check for migrationCompleted flag from Storage API on startup
- If not migrated, trigger migration
- Read LoadingScreenColor from Storage API first, fall back to localStorage if
not found
- Ensure UI displays correctly during migration
===============================================================================

Task: 3

Phase 3: Replace all localStorage calls with storage-wrapper throughout the
codebase.

Convert scripts/preload.js:
- Make it async (ES module with top-level await)
- Replace localStorage.getItem('LoadingScreenColor') with await
storageWrapper.get('LoadingScreenColor')
- Add error handling with default fallback

Update scripts/script.js:
- Wrap DOMContentLoaded content in async function
- Replace localStorage.getItem calls with await storageWrapper.get() calls
- Ensure UI updates happen after storage reads complete

Handle scripts/save-load-states.js:
- Convert all functions to async and use storage-wrapper
- OR remove file if unused and document replacement

Migrate high-usage files:
- weather.js: Replace localStorage with storage-wrapper (weather data → local,
API key → sync)
- search.js: Replace localStorage with storage-wrapper (preferences → sync)
- quotes.js: Keep quotes_* in localStorage, migrate other preferences to
storage-wrapper
- shortcuts.js: Replace localStorage with storage-wrapper (data → local)

Migrate remaining files (ai-tools.js, bookmarks.js, clock.js, theme.js, tips.js,
todo-list.js, wallpaper.js, etc.):
- Replace all localStorage calls with storage-wrapper
- Add async/await as needed
- Follow storage-config.js routing
===============================================================================

Task: 4

Phase 4: Update backup and restore to work with Storage API while maintaining
backward compatibility.

Update backupData() in scripts/backup-restore.js:
- Read from chrome.storage.sync and chrome.storage.local instead of localStorage
- Aggregate sync and local storage into unified object
- Merge quotes_* from localStorage and wallpapers from IndexedDB
- Maintain format: { localStorage: {...}, indexedDB: {...} }
- Add metadata flag to indicate Storage API source

Update restoreData() in scripts/backup-restore.js:
- Detect backup format by checking metadata flag
- For old backups: restore to localStorage, then trigger migration to Storage
API
- For new backups: restore directly to chrome.storage.sync/local based on
storage-config.js
- Keep IndexedDB restore logic unchanged
- Always preserve quotes_* in localStorage
- Clear localStorage after restore (except quotes_*)
===============================================================================

Task: 5

Phase 5: Add listeners for synced settings and handle updates from other
devices.

Add storage change listeners:
- In storage-wrapper.js (or new listener module), add
chrome.storage.onChanged.addListener
- Filter by storage area (sync/local) and key
- Emit custom events or callbacks when relevant settings change
- Handle delayed sync when coming back online

Update UI modules to respond to storage changes:
- theme.js: Listen for theme preference changes and apply
- clock.js: Listen for clock type changes and update
- search.js: Listen for search engine changes and update
- Add listeners for other synced UI preferences
- Prevent race conditions with initial load

Implement sync timing strategy:
- Load default values first (don't block rendering)
- Apply stored preferences when Storage API get() resolves
- Apply synced preferences when storage.onChanged fires
- Use timestamps/versions to determine most recent
- Batch updates to prevent flicker
===============================================================================

Task: 6

Phase 6: Clean up migration code, add quota monitoring, and validate the
implementation.

Remove localStorage fallbacks:
- Remove localStorage fallback reads from storage-wrapper.js (keep only Storage
API)
- Remove migration detection from preload.js
- Keep quotes_* in localStorage
- Keep wallpapers in IndexedDB

Add quota monitoring:
- Use chrome.storage.sync.getBytesInUse() before large writes
- Handle QUOTA_BYTES quota exceeded errors
- Respect 100KB total and 8KB per item limits
- Log warnings when approaching limits
- Fall back to chrome.storage.local if sync quota exceeded

Testing checklist:
- Fresh install (no data)
- Upgrade flow (localStorage → Storage API)
- Backup/restore with old backups
- Backup/restore with new backups
- Offline/online sync behavior
- No duplicate storage (except quotes_*)
- Wallpapers in IndexedDB only

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord or schedule a call!

[basupatil1213]

Hi Prem, I would like to fix this issue!

[prem-k-r]

Sure @basupatil1213, thanks!
Take your time, please take everything into consideration