IndexedDB version change and custom rollback procedure integration

Goal: guarantee that after an IndexedDB schema upgrade the application can revert to the previous object‑store layout without losing user‑generated data.

Constraint: IndexedDB only allows version numbers to increase; attempting to open a lower version throws a VersionError and does not automatically downgrade stores, so any rollback must rely on developer‑provided backup and restore logic, and the precise moment to capture a backup relative to the version‑change request is not defined by the specification.

What triggers the backup process relative to the version‑change request? When should the application interpret a VersionError as a cue to initiate restoration? Which storage mechanisms provide reliable snapshots for IndexedDB object stores across major browsers?