fix: prevent DualStore from clobbering VSS backups and mask-failing restores

[kaloudis]

Background

ZEUS users reported restore-from-seed coming up with no channels. Investigation traced it to the app-side VSS build timeout silently falling back to an empty local store (fixed separately in the ZEUS app), which exposed two independent defects in DualStore:

Problem 1: bulk sync clobbers VSS backups

DualStore::new unconditionally spawns bulk_sync_to_vss, which pushes every local key to VSS using unconditional puts (version: -1 skips the server's conflict check). If the local store contains a fresh node built over an existing backup — e.g. a restore that fell back to an empty local store — the sync overwrites the real manager key in VSS within seconds of the next launch. No user activity is required. The old channel monitors survive only because the fresh node has no monitor keys and the sync never deletes; recovery is then limited to orphan-monitor force-closes.

Problem 2: restore mode masks VSS failures as success

In restore mode, read() collapsed any VSS error into NotFound and list() into an empty namespace. A fast-failing VSS error — auth rejection from device clock skew (InvalidRequestError skips retries entirely), DNS failure — therefore made the node build fresh with no channels while reporting success, indistinguishable from a real restore at the API surface.

Changes

• Push safety gate (vss_push_allowed): all VSS pushes (bulk sync, per-key writes, removes) first verify the poison signature is absent: local has no channel monitors (active or archived) while VSS holds at least one. On detection, VSS writes are disabled for the session and a CRITICAL message is logged directing the user to re-restore. If VSS is unreachable during the check, the verdict stays undetermined: the current push is skipped (harmless — local retains the data and a later bulk sync catches up) and the check reruns on the next push. Healthy nodes short-circuit on the local monitor listing with no network call; restore-mode sessions pre-arm the gate open since their state derives from VSS.
• Restore-mode error propagation: non-NotFound VSS errors in read()/list() now propagate, failing the build so callers surface the error instead of silently producing a fresh node.
• Bulk sync skipped in restore mode: local started empty this session; there is nothing to catch up.

Notes

• Protects already-poisoned devices in the field the moment they run a build with this change, before their next launch clobbers the backup.
• Companion ZEUS app PR (restore hard-fail + startup handling) to follow; app changes are independent and safe to ship first.
• cargo check clean. Rebuilding LDKNodeFFI binaries + ZEUS fetch-libraries.sh checksum bump required to ship.

Known limitations of the push gate

• Defeated by new channel activity on a poisoned device: if a pre-fix victim opens a new channel from the fresh node, the local monitor listing becomes non-empty and pushes resume, overwriting the backed-up manager. Closing that hole would require content-level reconciliation; the gate protects the common case of an idle poisoned device.
• A confirmed-unsafe session runs with no VSS backup at all, including for new channels opened during it. The CRITICAL log's recovery instruction (restore from seed into a new wallet) is the intended path; a poisoned wallet should not be operated long-term.