ACF block's saved data (repeater sub-fields) silently blanked on normal Update — block `mode` flips to "preview" even without touching preview/expanded-editor UI

TITLE:
ACF block's saved data (repeater sub-fields) silently blanked on normal Update — block mode flips to "preview" even without touching preview/expanded-editor UI

BODY:
Describe the bug

A block registered via acf_register_block_type() (no acf_block_version set, so default V2/mode: edit behavior) containing a repeater field can have its mode attribute flip from "edit" to "preview" on a normal Save/Update click — with no one touching the block's preview/expanded-editor toggle. When this happens, every repeater sub-field value (e.g. image) is serialized as an empty string in the saved post_content, and the front end renders the block's static registration-time preview instead of the real content. This has happened twice in production for us in the last 24 hours, both times on ordinary edits (removing/updating repeater rows) via the standard sidebar "Block" panel — never via the pencil/expand icon or any preview toggle.

To Reproduce

We were not able to build a deterministic, isolated repro — this is what we reconstructed from two real production incidents via WordPress revision history and Apache access logs:

1. Register a block via acf_register_block_type() with 'mode' => 'edit' and a repeater sub-field (e.g. image + text), no acf_block_version set.
2. Open a page containing the block in the block editor. Click the block (not the pencil/expand icon) and edit a repeater row in the standard sidebar "Block" panel — the panel shows correct, real data.
3. Click Update.
4. Compare the resulting revision to the one before it: in both of our incidents, every block on the page had "mode":"edit" flip to "mode":"preview", and every repeater image sub-field flipped from a real attachment ID to "".
5. In both cases, saving again (Update) a second time, ~15–50 seconds later, produced a correct revision (mode:"edit", real values restored) — so the underlying field data was never actually lost, just the specific save was corrupted.

Apache access logs around the bad save show a burst of POST /wp-admin/admin-ajax.php requests (consistent with acf/ajax/fetch-block) in the 10–30 seconds immediately before the POST /wp-json/wp/v2/pages/{id} save request that produced the bad revision — in both incidents. We were not able to capture the exact in-browser request bodies live (both incidents were caught after the fact from logs), but the timing strongly suggests a race between an in-flight block preview/fetch and the block's attributes being read for serialization at save time — similar in spirit to the isFetchingBlock timing issues described in #1025, but manifesting as silent data loss on a normal save rather than a stuck UI.

Expected behavior

Clicking Update should never serialize a block's in-progress/loading state (mode: preview, blank repeater values) over real, already-saved data — either by not allowing the save to proceed while a block's data is still resolving, or by never letting a block's committed attributes regress to a default/blank state once real values have loaded.

Version Information

• WordPress: 7.1
• Advanced Custom Fields PRO: 6.8.8
• PHP: 8.3.6
• Block registered via acf_register_block_type() (PHP array registration, not block.json), 'mode' => 'edit', no acf_block_version set.

Additional context

This may be related to two other things we found while investigating:

1. A separate, purely cosmetic issue: without acf_block_version set, the editor canvas shows the block's registered example/preview image instead of a live render whenever the block isn't the actively-selected block. Setting acf_block_version: 3 fixes that, but on our repeater blocks it breaks the V3 "expanded editor" panel instead — every repeater sub-field renders blank in that panel's form (real data, correct on the server side, just not applied to the panel's inputs), which is why we reverted to the V2 default and are hitting the bug described above instead.
2. #1025 (filed today) describes the Expanded Editor becoming unresponsive during an in-flight block preview re-fetch (isFetchingBlock), which reads to us like the same underlying fetch/attribute-reconciliation timing area of the codebase, just a different symptom (stuck UI there, silently-blanked saved data here).

Happy to provide the exact revision content diffs (before/after JSON) and access log excerpts from our two incidents if useful — redacted to remove real customer data.

Start by comparing the revision content diffs and Apache access-log timing around acf/ajax/fetch-block and the wp-json/wp/v2/pages save request. Read issue #1025 for related isFetchingBlock behavior and trace how block attributes are reconciled before serialization. Done means reproducing the regression or establishing a regression test that prevents preview/loading state from overwriting repeater values during Update.