Tauri v2: no built-in integrity check for app data restored from user backups

I'm designing the restore flow for a Tauri v2 desktop app. Users can export their data (SQLite file plus some JSON state from the store plugin) to a backup folder, and later point the app at that folder to restore. The open question is how the app should decide whether the restored data is trustworthy and uncorrupted before replacing the current state.

The framework's existing verification mechanisms don't seem to cover this case. The updater plugin verifies update artifacts against an embedded Ed25519 public key, but as I understand it that protection applies only to update packages, not to arbitrary files the app reads at runtime. The fs plugin's scope system restricts which paths the frontend may read, but says nothing about whether the contents are valid. Persisted data surviving an update is a matter of OS path conventions, and schema validation is left to the app.

So the unresolved decision is what the canonical pattern is for verifying restored data in Tauri v2: checksums, signing the backup with an app-held key, or schema validation alone, and whether any of this belongs in Rust commands rather than the frontend, given that fs scopes do not constrain the backend.

Is there a documented or community-accepted approach for integrity verification of restored backups in Tauri v2? Should verification live in a Rust command to avoid trusting frontend-read bytes? And is there any updater-style signing primitive exposed for reuse on arbitrary data files?