GitHub Issue: Critical Replay Vulnerability in PersistedReplayGuard Due to Faulty Persistence Order

A critical security flaw in the `PersistedReplayGuard.advance()` function creates a replay attack vulnerability. The bug stems from a fundamental design violation: the function increments an outbound message counter in memory *before* persisting the new value to storage. This sequence directly contradicts the safer persist-first order mandated by the project's design documentation.

The current implementation in `PersistedReplayGuard.kt` follows a dangerous three-step process. First, it increments the counter in memory. Second, it attempts to write the new value to persistent storage. Third, it returns the counter for use in an outbound message. The core failure is the inversion of steps one and two. If the application process crashes after the in-memory increment but before the storage write completes, the system state becomes corrupted. Upon restart, the guard reloads the old, lower counter value from storage, effectively rolling back the increment.

This rollback creates a direct security breach. The next call to `advance()` will return the same counter value that was used for a message sent just before the crash. Any recipient system that received the pre-crash message will correctly flag the new, identical message as a replay and reject it. However, the vulnerability window is exposed for any recipient that *did not* receive the initial message; it will accept the replayed counter as valid. This flaw undermines the fundamental nonce guarantee, allowing for potential message duplication or replay attacks in distributed systems relying on this guard for security.