# Rust shared SBE ring counter rollover

The Rust mapped SBE ring now uses explicit wrapping arithmetic for its shared
64-bit counters. This prevents overflow panics in checked builds and preserves
the counter bit patterns used by Java and the default .NET build. The file layout,
atomic orderings, allocation behaviour and SPSC ownership contract are unchanged.
No lock was added and no latency improvement is claimed.

## Reproduced failure

Against source `cb3f6f334` with two new inline regressions, nine existing ring
tests passed and both new tests failed with an addition-overflow panic: publishing
the tail at `i64::MAX`, and incrementing a full-ring drop count at that limit.
The same unchecked arithmetic also governed head advancement and the producer's
cached head distance, so all five operations now explicitly wrap.

This is a seeded boundary reproduction, not a production failure observed on
the network. Naturally reaching the signed counter limit would require an
extraordinarily long run. Ordinary optimized Rust builds already disable these
overflow checks; the fix makes correctness independent of that compiler setting.

The FIFO test attaches separate producer and consumer mappings at both the
signed boundary and the negative-to-zero boundary. It fills the ring, verifies
refusal, releases and reuses a slot, attaches a replacement consumer, verifies
timestamps and payload order, then proves the ring empty. The second regression
proves drop-counter rollover leaves the full ring's payloads unchanged.

## Verification

Using Rust 1.92.0 and the standard checked test profile:

- All 11 ring tests passed in the development and open editions, including the
  existing 200,000-message two-thread FIFO and torn-slot test.
- The complete development library suite passed 910 tests with no failures or
  ignored tests. This was `cargo test --offline --lib`, not the integration or
  documentation test executables.
- The export scrub scan of the changed engine file reported zero findings.

Tests ran under an isolated CPU lease while shared-pool work could overlap.
They are functional coverage, not quiet-host latency evidence or a new live
Java/.NET cross-process interoperability run. The existing layout fixture checks
the shared bytes, and the new tests use two Rust mappings of that file.

Before source, baseline and fixed logs, open-edition output and full-library
results are kept in `~/archive/libhft/rust-ring-rollover-review-20261003/`.
Post-rebase verification and its source pin are retained separately.
