Add backup/restore and schema upgrade/rollback qualification

[TrendpilotAI]

Plain-language problem

A database is not operationally trustworthy until its history can be restored into a clean environment and still rebuild the same graph. A successful export command or server restart is not restore proof.

Technical cause

The preview has schema version metadata and restart tests, but it does not yet exercise backup/export, clean restore, provider schema upgrades, or rollback from an incompatible migration.

Proposed solution

Add fixtures containing multiple scopes, parent/fork runs, native relations, explicit nulls, and a failed projection. Exercise the SurrealDB-supported backup/export mechanism, restore into a distinct empty server, verify event integrity, and rebuild every ready projection.

Add a real v1-to-v2 migration fixture before changing SCHEMA_VERSION, including a documented rollback or forward-fix strategy.

Repeatable acceptance tests

• Restore into a clean namespace/database and verify every run count, sequence, head hash, parent/fork link, and canonical payload.
• Clear and replay projections; compare objects, relations, patches, and readiness state.
• Prove no source server or database is consulted after restore.
• Upgrade an on-disk v1 fixture to the next schema without data loss; reject unknown future versions.
• Record recovery time, recovery point, server/SDK versions, backup command, and artifact checksum.

Non-goals

• Do not call filesystem copying during live writes a qualified backup.
• Do not mark the project production-ready from restart tests alone.