test: add upgrade home fixture coverage

docs/production-readiness-roadmap.md

@@ -308,12 +308,15 @@ Goal: make first deployment the start of a controlled compatibility story.
     `cargo run`.
   - `[x]` Archives include relevant docs and license files.
 
-- `[ ]` Add upgrade tests.
+- `[x]` Add upgrade tests.
   Acceptance criteria:
-  - `[ ]` Fixture homes from previous tagged pre-releases migrate forward.
-  - `[ ]` Upgrade tests include store schema, config, keychain/auth logs, CAS
+  - `[x]` Fixture homes from previous tagged pre-releases migrate forward.
+    There are no tagged pre-releases yet, so the current test uses a synthetic
+    pre-release home and the release policy requires retaining real tagged
+    fixture homes once tags exist.
+  - `[x]` Upgrade tests include store schema, config, keychain/auth logs, CAS
     metadata, and peer cards.
-  - `[ ]` Rollback expectations are documented.
+  - `[x]` Rollback expectations are documented.
 
 - `[x]` Publish release and support policy.
   Acceptance criteria:

docs/release-support-policy.md

@@ -34,6 +34,19 @@ After the first deployment tag:
 - Signed operation formats must not be changed without a new version or
   explicit migration behavior.
 
+## Upgrade And Rollback
+
+Before the first deployment tag, upgrade tests use synthetic pre-release homes
+that exercise the same on-disk contracts as tagged fixtures: config, SQLite
+schema, signed keychain/auth logs, CAS metadata, and peer-card metadata. Once a
+tagged pre-release exists, its fixture home must be kept and migrated by the
+current test suite.
+
+Store migrations are forward-only. A newer daemon may upgrade `geth.sqlite` in
+place, so rollback means restoring a backup made before the upgrade or using a
+copied fixture home. Downgrading a migrated home with an older binary is not a
+supported recovery path unless a release note explicitly says so.
+
 ## Security Updates
 
 Security fixes should be released as soon as practical after validation. The