Persist per-identity token watch set across restarts in rs-platform-wallet

[lklimek]

User Story

As a wallet-app developer, I want rs-platform-wallet to persist the per-identity set of watched token IDs across restarts (and/or expose a durable opt-out), so that I can rely on the wallet as the source of truth for "currently tracked tokens" and durably honor a user's decision to stop tracking a token.

Expected Behavior

The per-identity token watch set survives an application restart. A downstream consumer can register the tokens it wants to track once, and on the next launch the wallet still knows that set without the consumer re-registering everything. A user's "stop tracking this token" (unwatch) decision is durable — it is not silently re-added on the next refresh or restart. Ideally there is also a durable opt-out so an explicit unwatch cannot be undone by a blind re-registration.

Current Behavior

IdentitySyncManager owns the per-identity set of watched token IDs only in memory:

state: RwLock<BTreeMap<Identifier, IdentityTokenSyncState>>

The three mutators — register_identity, unregister_identity, and update_watched_tokens — never persist this set. The sqlite persister writes only balance values (TokenBalanceChangeSet), and the load payload (ClientWalletStartState) has no token-watch field. As a result the watch set is wiped on every app restart.

Consequences for a downstream consumer (Dash Evo Tool):

• It must re-register the entire local token registry for every identity on each launch — wasteful and redundant.
• A user's "stop tracking this token" decision cannot be durably honored: after a refresh/restart the consumer re-registers its full registry, silently re-adding tokens the user explicitly dismissed.

Possible Solution

Persist the per-identity token watch set in the sqlite store alongside the balance change sets:

• Extend the persister to write/read the watched token IDs per identity (not just TokenBalanceChangeSet values).
• Add a token-watch field to the load payload (ClientWalletStartState) so the set is rehydrated on startup.
• Have register_identity / unregister_identity / update_watched_tokens write through to the store so the in-memory state map is durable.

Alternatives Considered

• A durable per-identity opt-out / dismissal list (persisted "do not watch" set) that a blind re-registration cannot override. This would let consumers keep registering their full registry while still respecting explicit user unwatches. Could be offered instead of, or in addition to, full watch-set persistence.
• Pushing all of this into the consumer (Dash Evo Tool maintaining its own durable watch set and reconciling on each launch). This duplicates state the wallet already models in memory and makes the wallet's watch set non-authoritative, so it is not preferred.

Additional Context

Filed by a downstream consumer (Dash Evo Tool) that depends on rs-platform-wallet and currently cannot treat the wallet's watch set as a durable source of truth.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}