5.2.0 data-migration stamp not durably persisted — upgrade process re-ran on consecutive boots (data version stayed 5.1.26)

### Symptom

On an instance upgraded in-place from 5.1.26 to 5.2.0, **two consecutive boots** both logged:

```
[notify] Starting upgrade process: applying 1 data migration to bring data from 5.1.26 up to software 5.2.0.
[notify] Applying migration 1 of 1 (introduced in 5.2.0): create system.hdb_secret table for the secrets store
```

i.e. the recorded data version was still 5.1.26 at the second boot — the stamp from the first migration run did not persist. A later boot showed no upgrade lines, so it eventually stuck; the migration itself appears idempotent (`system.hdb_secret` contents survived), but the stamp write is evidently not reliably durable at the time the migration completes.

### Why it matters

A create-table migration re-running on every boot is only safe while every migration happens to be idempotent; the stamp is the invariant. Worth checking whether the data-version write is ordered/synced correctly relative to migration completion (observed on a Fabric-hosted harper-pro 5.2.0 container; timestamps and boot evidence available).

No file or test is named. Start by tracing the data-version write and migration completion path behind the reported upgrade logs, then reproduce consecutive boots from 5.1.26 to 5.2.0. Done means the 5.2.0 stamp is durably persisted before migration completion and the migration does not run again on the next boot.

Written by the indexing model from the issue text.