JetStream snapshot restore compatibility with NATS 2.10 backup format headers

When restoring a JetStream stream from a snapshot backup, the interaction between the backup format version and the target server release creates a compatibility boundary affecting stream data and consumer state. Snapshots created with NATS 2.10 include a version header in the backup format, and the nats-restore tool is documented to restore snapshots only to the same or a newer NATS version. This creates a practical uncertainty for operators maintaining mixed-version clusters or staging restore targets.

Beyond the format header, snapshot backups capture stream data and metadata but omit consumer state unless explicitly exported. There is currently no automated mechanism to re-create consumer state during restore, so consumers must be recreated manually after the stream is available. Additionally, restoring to a server with a different cluster ID will orphan the stream, requiring the cluster ID to match before restore.

Given these constraints, what is the supported path for restoring a NATS 2.10 snapshot to a target server running an earlier release, and does the version header prevent the restore outright or merely signal a format change? Is there a documented workflow for exporting and re-importing consumer configurations alongside a stream snapshot when the restore target predates automated consumer state handling? How should operators verify that restored stream data and any manually recreated consumers match the original backup without relying on undocumented restore behavior?