[rt2zz]

Closes #1397, closes #1281, closes #1298.

Stacked on #1521 (it touches the same REHYDRATE branch); merge that first. One change per commit:

• Storage engines can return values instead of promises (Persistoid crashes in react-native testing library #1397, Synchronous store (no async/await Promises, react-native-mmkv) #1281). persistStore called .then on whatever getItem returned, so a synchronous engine or a Jest mock (jest.fn() returns undefined) crashed with "Cannot read properties of undefined (reading 'then')". Each storage call is now wrapped in a promise: a value, a promise and a throw all work, and a throw is handled like a failed read or write. setItem is still called synchronously, so flush() in beforeunload keeps writing right away.
• A purged parent passes nested REHYDRATE through. After persistor.purge(), a persistReducer ignored REHYDRATE for every key, not just its own, and didn't pass it on. So a nested persistReducer whose read finished after the purge (logging out right at startup) never rehydrated and never saved again. So did one added later with code splitting. Found while checking After purge it stops persisting #883 against v7; v6 had it too.
• A read that finishes after a purge brings nothing back (from review of the previous commit). Without this, the late REHYDRATE passing through could make a parent that also stores the child save its whole pre-purge state, and plain reducers reading that REHYDRATE got the purged payload. Such a read now delivers no payload, and a purged store passing a nested REHYDRATE through doesn't save.
• A read that rejects without a reason is a failed read (older bug, found in review). reject() with no error was taken for empty storage, so initial state was saved over the stored data. An engine in our community list does this. Same for migrations. A callback-style getItem(key, cb) that returns nothing is now a failed read with a clear message too, instead of reading as empty storage.
• Frozen in, frozen out, from startup (Incorrect work with immer immutable state first level. #1298). With Redux Toolkit (immer), every level of state was frozen except the top-level object persistReducer creates to add _persist. It's now frozen when the reducer's state, or the state persistReducer was given, is frozen. Unfrozen state is untouched.
• Warning when replaceReducer changes the storage key (Dynamic keyPrefix for Multiple Users #1112). Swapping in a persistReducer with another key/keyPrefix (a common attempt at per-user storage) keeps the current state and writes it over what's stored under the new key, without loading anything. That's now a development error pointing to a new store and persistor; the docs PR has that recipe. Hot reloading with the same key doesn't warn.

Tests: storageValues.spec.ts, purgeNested.spec.ts, frozenState.spec.ts, replaceKey.spec.ts. Each fails without its commit (except the "doesn't freeze" and "doesn't warn" guards). 157 tests pass across repeated runs.

An adversarial review ran scenario scripts covering:

• write ordering
• sync throws
• the community storage engines' signatures
• devtools replays
• RTK and redux-undo
• nested persists
• the warning's false positives

The purge, rejection and freeze commits address what it found. Known limits, not fixed here:

• swapping in a different storage instance under the same key isn't detected
• changing key while Redux DevTools replays stops saving silently, though stored data stays intact

No dependency changes.