persistence: v1->v2 upgrade test + honest README

README §6 claimed bidirectional forward-compat for journal records.
Reality is narrower:

- ProcessJobStore (kVersion=2) and SubstrateStore (kVersion=2) accept
  v1 records on replay — their loaders explicitly switch on the version
  byte and treat the v2 trailer fields as empty when absent.  This is
  the actual upgrade path the README half-described.

- ControlJobStore, CarrierStore, LoadPortStore, ExceptionStore, and
  SpoolStore use strict `header[1] != kVersion` rejection.  A future
  kVersion bump there without a matching loader-side dispatch would
  silently nuke every replayed record.  The README sold this as a
  feature; it isn't yet.

This commit adds:

- tests/test_persistence_upgrade.cpp: five cases that craft journal
  records byte-by-byte so format drift is caught (no codec round-trip
  hiding the field layout).  PJ v1 -> v2 read; PJ v1 rewrite stamps
  current kVersion=2; PJ unknown future version rejected; Substrate
  v1 read with empty history trailer; CJ + Carrier reject unknown
  versions (tripwire for the strict-version stores).

- README §6: replaces the rosy "newer versions ignore unknown
  trailers" claim with what's actually implemented — multi-version
  reads on PJ + Substrate, strict equality elsewhere — and points
  at the test as the contract anchor.

When the strict-version stores grow their own v2, the rejection
tests will need to flip to acceptance; the layout is right there in
the test so the edit is mechanical.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

README.md

@@ -315,10 +315,18 @@ new dictionary loads.  Code changes do require rebuild + restart.
   promote.
 - **Code upgrades**: deploy to a canary tool first; bake-test for
   at least a full wafer batch before fleet-wide rollout.
-- **Schema migrations**: persistence records are versioned (v1, v2)
-  and forward-compatible.  Older versions still load; newer
-  versions ignore unknown trailers.  Always test the upgrade with
-  a real on-disk journal before fleet rollout.
+- **Schema migrations**: persistence records carry a 1-byte version
+  stamp after the magic byte.  `ProcessJobStore` and `SubstrateStore`
+  currently implement multi-version reads: code at kVersion=2 still
+  loads v1 records (the v2 trailer fields default to empty).  The
+  remaining stores (`ControlJobStore`, `CarrierStore`, `LoadPortStore`,
+  `ExceptionStore`, `SpoolStore`) use strict version equality — a
+  future kVersion bump there requires adding a parser for the prior
+  version at the same time, otherwise replay will reject old records.
+  Tests in `tests/test_persistence_upgrade.cpp` lock down both
+  contracts and act as a tripwire if a kVersion bumps silently.
+  Always test the upgrade with a real on-disk journal before fleet
+  rollout.
 
 ## 7. Integration with the fab stack