Verifying data restored with structuredClone() when prototypes and descriptors are lost

I am designing an in-memory snapshot-and-restore flow for a JavaScript application state tree, using the global structuredClone() as the copy mechanism. The goal is to take a snapshot, mutate the live state, restore from the snapshot, and then prove the restored data matches what was captured.

The documented behavior creates a verification gap. Class instances come back as plain objects, so instanceof and constructor checks fail on restored values. Accessor properties are flattened to plain values, non-enumerable own properties are skipped, and functions throw a DataCloneError. Successful cloning therefore only proves a structural copy happened, not that the recovered data is intact or semantically equivalent.

There is also no deep-equality primitive in the standard library, so the restore procedure must decide how to validate the result. Constraints: the state tree contains Map, Set, Date and cyclic references, and the code must run on modern browsers plus a Node.js version where structuredClone availability still needs to be confirmed via feature detection.

Given these limits, should verification rely on a structural deep comparison of own properties and collection entries, on schema validation, or on both? Is there a documented way to detect which fields were silently dropped during cloning? And how should prototype loss be handled when downstream logic depends on class methods?