fix(app): encrypt note secrets at rest and reuse session keys per account

[Yue-Zhou1]

Addresses #71.

Summary

• encrypt note privateKey and blinding before storing them in IndexedDB using AES-256-GCM via the Web Crypto API; no new npm dependencies
• make saveNote() and importNotes() fail closed instead of falling back to plaintext when encryption keys are not yet derived
• migrate existing plaintext notes to encrypted storage on wallet connect when keys are available, or lazily on first note read
• keep note exports decrypted so backup files remain portable
• cache derived keys in session memory per account so a single account can make multiple spends in one session without signing again for each transaction, and switching A -> B -> A reuses A's cached keys
• clear all cached keys on disconnect
• add regression tests for encrypted note storage, migration-adjacent flows, and session key reuse

Trade-offs

• Derived keys are cached only in memory, bucketed per account, to avoid repeated prompts for both multiple transactions from one account and A -> B -> A account switching.
• Keys are not persisted to IndexedDB, localStorage, or sessionStorage, so refresh and disconnect still require signing again.
• The accepted risk is that a tab-memory compromise exposes derived keys for all accounts that signed in during the session, not just the active one, until disconnect or reload. Note secrets remain encrypted at rest regardless.

Test Plan

• cd app && npm test -- --runInBand js/__tests__/notes-store.test.js
• cd app && npm test -- --runInBand js/__tests__/ui.test.js
• cd app && npm test -- --runInBand

[maksimryndin]

we should take into account #139 also and probably consider native sqlite encryption features.

[maksimryndin]

thanks a lot @Yue-Zhou1 ❤️

we will need to close it as the general refactoring was done #148

but hope to reuse your work!