ReFS integrity streams on Windows 11: confirming retried writes stay logically single

Goal

I want to use ReFS integrity streams on Windows 11 so that transient I/O errors are retried by the storage stack without producing duplicate logical writes visible to my application. The file is opened with FILE_FLAG_WRITE_THROUGH on a volume formatted with the integrity option.

Constraints and uncertainty

The retry behavior is internal to the kernel, so from user mode I cannot tell whether a retry occurred or whether the write path was duplicated at any layer. The documentation I have found describes checksum verification and repair, but is less explicit about the exact conditions under which a failed write is retried versus surfaced as an error, and whether any file-open flags beyond write-through change that behavior.

I am also unsure how to observe retry counts in practice. Process Monitor shows logical writes, but I do not know whether kernel tracing or Windows Performance Analyzer exposes a counter that distinguishes a retried write from a normal one.

Questions

1. Under what conditions does ReFS retry a failed write on an integrity-stream file instead of returning an error to the caller?
2. Is FILE_FLAG_WRITE_THROUGH required for reliable retry semantics, or does FILE_FLAG_NO_BUFFERING also qualify?
3. Which ETW provider or performance counter exposes internal write-retry counts so I can verify no duplicate logical writes occur?