Refill an emptied VSS store from local state at unlock

[dcorral]

Refill an emptied VSS store from local state at unlock

Issue

When the VSS server loses its data (stack stopped, postgres data dir wiped, server restarted) and the node is restarted against the now-empty store, nothing re-uploads the node's existing state. The node keeps working normally because reads are local-first, but the rebuilt VSS store is silently incomplete: /vssbackupinfo reports backup_exists: false and backup_required: false, and the store only receives the handful of keys that happen to be rewritten after the restart. A later disk loss would restore without the RGB wallet and without every channel whose monitor was not rewritten since the wipe.

Two independent gaps cause this:

• The RGB wallet auto-backup in rgb-lib only tracks local changes (last operation timestamp vs last backup timestamp). It never asks the server whether a backup exists, so a wiped server stays empty until the next asset operation. The same logic leaves a fresh wallet's store empty until its first operation.
• The node's VSS restore only runs when the local DB has no channel manager. There was a remote-to-local restore path but no local-to-remote counterpart, so local keys were never reconciled against the remote.

Reproduction

1. Start a node with --vss-url, init and unlock it, then lock it.
2. Delete every key from both VSS stores of the node (the node store and its _rgb companion).
3. Unlock the node again.

Before this PR: the channel manager key is absent from the VSS store and /vssbackupinfo reports backup_exists: false. The e2e test vss_wiped_store_is_refilled_on_unlock reproduces this and fails on key missing after refill: _/_/manager when the refill is disabled.

Fix

• SyncedKvStore::push_missing_to_vss lists the remote keys once and writes every local row the remote lacks. It never overwrites a key the remote already holds, and it skips rows that are local-only by design: the pending replication queue, the consignment re-import marker, network graph and scorer. It runs at unlock whenever local state exists, so a wiped or partial store is refilled before the background processor starts.
• After the RGB auto-backup is configured at unlock, the node asks the server whether a backup exists and uploads one if not. This covers both the wiped store and the fresh wallet case.
• Support code: VssKvStore::list_all_keys (paginated key listing without values), SeaOrmKvStore::list_all, and the existing remove path split into remove_raw so tests can wipe rgb-lib's backup keys, which do not follow the node's key format.

Both failures at unlock (resync or initial RGB upload) abort the unlock with an explicit error rather than silently running with an incomplete backup.

Tests

• synced_kv_store_push_fills_missing_remote_keys (unit, needs the VSS server): wipes the remote, plants a foreign value, and asserts that missing keys are pushed, the existing value is not overwritten, local-only rows stay local, and a second push is a no-op.
• vss_wiped_store_is_refilled_on_unlock (e2e): init, unlock, lock, wipe both stores, unlock again, then asserts every key present before the wipe is back and /vssbackupinfo reports backup_exists: true.