EEPROM.update() compatibility boundary between AVR and ESP32 cores

I am designing a retry-safe configuration store for a sketch that must run on both AVR boards and ESP32 cores. The goal is to use EEPROM.update() so that repeated attempts with identical values do not consume additional write cycles, while still handling power-loss interruption for multi-byte records. On AVR cores, update() programs the cell immediately when the value differs, but on ESP32 cores the library emulates EEPROM in RAM and requires EEPROM.commit() to persist to flash. Because update() returns void, a skipped write and a failed write are indistinguishable at the API level.

The unresolved decision is how to structure a retry loop that preserves the no-op behavior of update() on AVR while ensuring the same data survives a reset on ESP32. I also need to decide whether to add an application-level integrity check for multi-byte records, since the library provides no checksum or journal, and whether to implement a ring-buffer layout to avoid concentrating writes on fixed addresses.

Which persistence boundary should the retry logic treat as authoritative: the immediate AVR write or the deferred ESP32 commit? Is there a documented core-agnostic pattern that keeps update() idempotent without silently dropping data on ESP32? For multi-byte structures, what is the minimal integrity framing the application must add to detect torn writes after a power loss?