test(upgrade): in-place node-by-node v4→v5 upgrade + per-node LMDB→RocksDB flip under sustained writes

## Gap

The highest-priority upgrade procedure — node-by-node in-place v4→v5 upgrade with a per-node LMDB→RocksDB storage flip in a **live, writing** cluster — has never been run end-to-end.

Current coverage stops short:
- core `integrationTests/upgrade/4.x-upgrade.test.ts` exercises single-node LMDB→RocksDB migration (`storage.migrateOnStart`) only.
- harper-pro `replicationTopology.test.mjs` exercises v4→v5 data flow into an otherwise-v5 cluster, but not an in-place rolling upgrade of a multi-node cluster under sustained write load.

The risky, untested middle is **mixed-version + mixed-storage replication during the rollout** (v5/RocksDB ↔ v4/LMDB), per node, while writes are flowing.

## Acceptance

- Stand up a multi-node v4 cluster (`harperdb@4`, LMDB) with seed data.
- Begin sustained write traffic to simulate active replication.
- Take one node offline → upgrade to v5 → `storage.migrateOnStart: true` (LMDB→RocksDB) → rejoin.
- Assert the upgraded node catches up on writes that happened while it was offline.
- Assert **bidirectional** replication between the v5/RocksDB node and the remaining v4/LMDB nodes (writes originating on either side land on the other).
- Repeat per node, one at a time; final cluster consistent with start + all writes performed during the test.
- Capture any required config changes (e.g. `clustering:` → `replication:`); log anomalies with repro.

## Basis / refs

- Builds on core `4.x-upgrade.test.ts` (single-node migrate) + harper-pro `replicationTopology.test.mjs` legacy fixture (`HARPER_LEGACY_VERSION_PATH`).

Likely needs a dedicated harness; may run nightly/manual rather than PR CI.

---
🤖 Generated with [Claude Code](https://claude.com/claude-code)