v0.276.0: a restore and a drive move keep the app's records (R-697, R-700)

A drive move persisted through the restore's fresh app.yaml write and dropped the pin: the syncer
then copied the catalog verbatim and the next start jumped the app past its ladder (R-700).
persistDriveFlip now changes HDD_PATH and nothing else. The restore's write carries the life
records (conversion copies, desired_state, update history) from the app.yaml it replaces, and a
second conversion no longer overwrites the first kept copy's record (R-697).

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

CHANGELOG.md

@@ -1,3 +1,23 @@
+## v0.276.0 — a restore and a drive move keep the app's records (R-697, R-700) (2026-09-27)
+
+**MinAgent: 0.131.0** (unchanged). Needs hub v0.123.0 (unchanged). New strings: none. Evidence:
+`felhom.eu/documentation/audits/records-carried-2026-09-27/`.
+
+- **R-700 (new, found reading the code for R-697): a drive move unpinned the app.** `doFlipRedeploy` persisted
+  through the restore's fresh `app.yaml` write, which drops `pinned_images`, `desired_state`, `installed_images`, the
+  update records and the kept conversion copies. Unpinned, the catalog syncer copies the catalog's compose verbatim
+  and the next start takes the newest version — past the ladder, and for a PostgreSQL app past its conversion step.
+  Now `persistDriveFlip` changes `HDD_PATH` and nothing else (load-then-save); the up-and-report tail is
+  `upFromAppConfig`, shared with `RedeployFromEnv`.
+- **R-697: a restore dropped the kept pre-conversion copy's record, so the copy was never released.** The restore's
+  write (`PersistUnitRedeployConfig`) now carries the app's life records from the `app.yaml` it replaces
+  (`carryLifeRecords`): `conversion_copy`, `earlier_conversion_copies`, `desired_state` (dropped, a dead app after a
+  restore read as "unknown intent" and was never alarmed), `failed_update_step`, `last_update_undone`,
+  `last_auto_update`. Not carried: the pin (the restore pins to the unit), `installed_images` (an observation of what
+  ran before). And a second conversion after a restore to the old major no longer overwrites the first copy's record:
+  it moves to `earlier_conversion_copies`, released by the same rule.
+- Tests: `internal/stacks/r700_records_carried_test.go` (4). Red-proofs RP1–RP4, each seen failing.
+
 ## v0.275.0 — a backup's data and its version travel together (R-696, `07` §6.6, D4 option A); R-695, R-691, R-694, R-699 (2026-09-26)
 
 **MinAgent: 0.131.0** (unchanged). Needs hub v0.123.0 (unchanged). New strings: yes (hu + en, 5 keys). Evidence: