# SCAN partial/unstable review — 2026-09-08

The retained raw samples reproduce the published stability qualifications for
five investigated v4 cells. No classifier discrepancy was found: all 98
per-session verdicts, logged percentile means and 13 process verdicts matched.
Every investigated session completed all 60,000 measured samples, with no deficit
or shed offers. Here, `partial` describes unstable latency, not missing replies.

| Retained cell | Per-session verdicts | Cause of the stability qualification |
| --- | --- | --- |
| C++ / kernel / pool, 19:27 UTC | 28 PASS, 4 WARN | Four sessions' service p99 CV is 10.45–15.02%, above the 10% warning limit. |
| C++ / VMA / pool, 19:29 UTC | 30 PASS, 2 WARN | Two sessions' service p50 CV is 5.72% / 6.13%, above the 5% warning limit. |
| Java-pure / kernel / single | 1 FAIL | Service p99.9 is 144.515 / 37.785 / 37.344 µs across runs; CV 84.34%. |
| Java-pure / VMA / single | 1 FAIL | Service p99.9 is 31.117 / 10.536 / 10.237 µs across runs; CV 69.20%. |
| .NET Pure / VMA / pool | 32 PASS | Control case: all sessions satisfy the existing limits. |

The old C++ pool cells also have independently proven coordinator/worker
contention. A fresh, separately archived rerun with coordinator19, workers10–13
and clients15–18 completed at 20:27:20 UTC. Both new cells delivered every sample
and passed startup placement checks, with no live-watcher violation, but still
carry latency instability qualifications. Their fresh raw replay also matches
all 64 per-session and eight process classifications: 30 PASS and two WARN
sessions per cell. Kernel's two p99 CVs are 13.8601%/13.6144%; VMA's two p50
CVs are 5.16455%/5.89245%. These are different warning sessions from the old
sitting. One pair of sittings does not establish a performance improvement.
Moving the coordinator fixes the placement defect;
it does not prove that every source of latency variability disappears.

Both Java single results have a much higher first-run tail. This is evidence of
run-to-run variation, not yet proof of JIT, GC, scheduling, transport or a warmup
defect. No run is discarded and no threshold is relaxed. Diagnostics must identify
the mechanism before changing the canonical recipe.

## Method and evidence

Service samples are decoded from each retained HFTBRW1 raw file, grouped by actual
session and measured run, then used to reconstruct the shipping percentile and
sample-standard-deviation/mean calculation. Sessions are classified separately;
the cell retains the worst qualification. Computing CV across pooled sessions
would test a different quantity and can hide unstable sessions.

Unchanged strict `>` limits: warning p50/p99/p99.9 = 5%/10%/25%; failure =
10%/25%/50%. Completion and sample-deficit checks take precedence. This is an
ordered binary64 source-math replay, not a cross-compiler/JIT bit-pattern proof.
No rounding tolerance or alternate classification was accepted.

Detailed per-run values, comparisons, source/raw/log hashes and captured installed
artifact identities are retained on SCAN in:

`/home/yann/libhft-bench-runs/stability-actual-replay-20260908-5WC2eR/replay.json`

The replay's classifier-source hashes match each original sitting's frozen
manifest. Original raw evidence remains in the `java-single` and `remaining`
subdirectories of:

`/home/yann/libhft-bench-runs/open-v4-mellanox-followup-20260908-8JscCC/`

These findings apply to those retained runs, not automatically to later
replacement rows in the live matrix.

Fresh rerun replay and live-role evidence:

`/home/yann/libhft-bench-runs/pool-coordinator-stability-replay-20260908-i0k0hc/`

Every measured run has an interior PASS sample showing the coordinator, four
workers and four clients on their separate declared CPUs. All 43 watcher samples
are retained: 28 PASS, 14 INCONCLUSIVE with no applications, one INCONCLUSIVE
across kernel shutdown, and no VIOLATION or INVALID. Phase matching uses retained
release-file mtimes and the configured two-second future lead, checked against
a same-boot clock anchor. The watcher did not capture joint realtime/monotonic
timestamps, so this association assumes no historical wall-clock step; it is not
proof of continuous coverage. Shutdown boundaries remain inconclusive.

## Java first-run tail: narrowed, not yet explained

The retained Java-pure single-session kernel and VMA runs both place their
largest first-run service sample at zero-based reply ordinal 991, whose scheduled
offset is 19.840 ms. The service maxima are 233.427 µs (kernel) and 196.344 µs
(VMA); the largest subsequent scheduler delays occur at ordinals 994 and 993.
This describes a service spike followed by catch-up, not evidence that pacing
alone caused the first spike. Later runs have their service maximum at ordinal 0.

All 120,000 retained measured response/service/scheduler triplets were checked,
including response = service + scheduler delay. No early samples were excluded
from publication. Evidence and reconstruction limits are retained in
`/home/yann/libhft-bench-runs/java-single-tail-chronology-20260908-sB5TmV/`.

Source review independently found a warmup coverage gap in the Java v4 client:
warmup exercises transport/parsing/correlation, but skips the service, response
and scheduler sample stores taken during measurement. Pre-clearing the arrays
touches memory but does not exercise those branch profiles. The first measured
scheduler store occurs after actual send and before receive, so first-use
runtime work there could affect service as well as response. This is a mechanism
to test, not proof of JIT or GC: the old run retained neither event stream.
The unchanged-workload GC/safepoint diagnostic completed separately; its
instrumented measurements did not replace the canonical rows. All four logs
were retained and neither transport lost a measured reply. They contain no GC
collection record. No measured service or scheduler interval overlaps a modeled
recorded safepoint window; the closest expanded window is 120.994 ms away.
The model includes a 1.659 µs endpoint clock envelope and ±1 ms printed-time
uncertainty, but assumes no intervening clock excursion or unbounded logging
delay. Kernel's first-run maximum repeats at ordinal 991; VMA's moves to 527.
This is not JIT evidence or retroactive proof about the old uninstrumented run.
Detailed correlation is retained under
`/home/yann/libhft-bench-runs/java-single-gc-live-l9p9y5t4/correlation-review-PpR2yI/`.

The recording-path regression now reproduces the old gap (three expected
warmup records versus zero). The corrected Java v4 path fills the existing
scratch service/response/scheduler arrays in both phases, then discards warmup
records at the existing preparation boundary. Only measured phases commit raw
series, totals, extraction snapshots and the measured in-flight maximum. Counts,
rate, barriers, watchdogs and stability limits are unchanged. Both new tests,
the 53-test MultiClient/barrier suite and the strengthened measured-sink audits
pass. The matching production rebuild is staged and the uninstrumented kernel
and VMA single-session cells completed at 21:22:46/21:23:46 UTC. Each delivered
all 60,000 measured replies, but both still qualify as unstable. The correction
has not eliminated the remaining variation; raw chronological comparison is
complete. Kernel service p99.9 is 111.164/35.602/39.585 µs across runs
(CV 68.4557%); VMA is 42.076/10.226/10.254 µs (CV 88.1476%). Both exceed the
unchanged 50% failure limit. The new first-run maxima move to ordinals 198
(kernel, 203.556 µs) and 674 (VMA, 175.933 µs), so ordinal 991 is not a fixed
property of the corrected path. All 120,000 raw triplets and both classifications
reconcile; early measured samples remain included. Detailed comparison:
`/home/yann/libhft-bench-runs/provider-corrections-rerun-20260908-PNfKFd/java-warmup-chronology-review-O7KLqG/`.
See [the new result archive](open-sweep-scan-java-warmup-recording-v4.json).

## .NET Native/kernel single control

The fresh canonical control completed at 22:40:34 UTC on 2026-09-08, using
the verified build from `0de7a00f`, before the proposed warmup-recording fix.
All six phases delivered their 20,000 requests: 60,000 warmup and 60,000
measured exchanges, with no shedding, refused sends or outstanding requests.
Measured throughput is 49,997/s. Service p50/p99/p99.9/max is
22.794/31.102/43.153/250.078 µs; response is
24.767/33.747/175.488/264.483 µs.

The previous saturation is not reproduced: per-run scheduler p99 is
7.868/7.148/7.125 µs, mean 7.380333 µs, below the unchanged 20 µs gate.
The remaining `partial` label is solely a service-p50 warning. Run medians
24.394/21.927/22.060 µs give sample CV 6.087322%, above 5% but below the
10% failure boundary. Service p99 and p99.9 CVs pass at 1.091861% and 2.663629%.

An early timing disturbance remains. Reconstructed one-based measured ordinals
2–66 in run one have scheduler delay above 20 µs, peaking at 537.812 µs at
ordinal four. Run two has no such late requests; run three has ordinal two and
16,525–16,535. These are task timestamps reconstructed from the fixed schedule
and paired raw samples, not wire timestamps or evidence of a particular JIT,
GC, transport or server-capacity cause. This control follows multiple source
corrections, so its comparison with the old 617-slot episode is not a
one-factor causal experiment.

Independent replay validates all nine raw series, 60,000 samples per probe,
no drops/clamps, exact response = service + scheduler delay, the direct raw
argument binding, all 52 inventoried installed hashes and six selected source
hashes. The watcher retains two PASS and three INCONCLUSIVE samples, with no
VIOLATION; this is not continuous placement proof. The earlier saturated row
remains in its historical archive. See the
[new canonical archive](open-sweep-scan-native-kernel-single-capture-correction-v4.json)
and `/home/yann/libhft-bench-runs/provider-pool-coordinator-rerun-20260908-HwCwOk/DOTNET-NATIVE-KERNEL-SINGLE-INDEPENDENT-REVIEW.md`.

## V4 warmup recording parity — 2026-09-09

C++ and both .NET manual OPEN paths were still skipping sample storage during
warmup. Java's corresponding v4 mismatch was already corrected. The new change
prepares/touches service, response and scheduler buffers before warmup readiness
and performs the same recording operations in both phases. Warmup buffers are
discarded, never passed to raw export or measured reporting. C++ now uses an
explicit measured-phase flag for elapsed time, overload counts and in-flight
peaks: buffer presence can no longer incorrectly imply measured work. Legacy
v3 warmup remains unchanged. No clock, target, schedule, cap or threshold changes.

The managed recording helper is inlined by this runtime. Preparing the actual
Release native entry point without invoking it showed that its much larger
method did not inline the proposed helper despite AggressiveInlining. Native
recording therefore remains literal List.Add operations inside the loop.
The final disassembly of all three relevant driver methods has no recorder
helper calls. This checks local code generation, not a live latency improvement.

Validation: 213 MultiClient tests pass, including 13 new tests of managed
recording, real extraction/reporting/raw serialization and both actual source
paths. Native sample construction in the isolated fixture is not execution of
its Main; exact inline stores and phase boundaries are separately checked by
source mutations. C++ actual-helper/result/serialization tests pass at GCC 14
O3 and ASan/UBSan with leak detection; three wiring tests cover 16 original mutations plus conditional, commented
and arithmetic changes. The OPEN ownership and measured-sink audits pass
17 and 27 tests respectively; protocol parity passes all 147 checks.
Original source snapshots are rejected by the new checks. Evidence and exact
JIT disassembly: `/tmp/libhft-warmup-validation-20260909-Shhrs7/`.

Production rebuild/staging completed on 2026-09-09: C++ kernel/interposition and
SocketXtreme plus both C# application trees were built from `ec56e941`, with
unchanged source/configuration manifests. The .NET Native library was already
up to date, not newly compiled. Java remains bound to its unchanged `0de7a00f`
build. Host-side verification passes 88 build/stage/installed comparisons,
48 unique installed files and 61 ownership/permission checks. These counts are
not counts of new compilations. Evidence:
`/tmp/libhft-warmup-build-20260909-sBBfDB/README.md` and
`stage-verification-host.json`. The initial sandbox check is preserved: its
root-ownership remapping required verification in the actual host namespace.

The first fresh .NET Native/kernel SINGLE completed at **22:06:57 UTC**:
service p50/p99/p99.9/max **23.349 / 30.595 / 38.144 / 76.555 µs**, response
**25.278 / 33.279 / 41.206 / 78.474 µs**, **49,997/s** achieved at 50,000/s.
All 60,000 measured and 60,000 warmup offers completed, with no shedding,
refusal, outstanding request, native error or event-ring drop. The nine raw
series contain exactly 60,000 samples per probe, no raw drops/clamps and exact
response = service + scheduler delay. All 52 installed inventory hashes match.

It remains **partial: service p50 WARN**, not saturated. Its p50 runs are
25.000 / 22.406 / 22.640 µs, sample CV **6.1454%**; p99/p99.9 CVs pass. Scheduler
p99 is **7.411 µs**, below the unchanged 20 µs gate. Only three requests exceed
20 µs of scheduler delay (two in run 1, one in run 2), with a maximum of
20.699 µs. The previous 65-request first-run late cluster is absent in this
new sitting, but the first-run median shift remains. These different-day
observations are not a paired causal experiment: the parity fix does not yet
explain or resolve the remaining service variation.

Startup affinity passes; the live watcher retains two PASS and three
INCONCLUSIVE samples, no VIOLATION or INVALID. Sampled observations are not
continuous placement proof. The old rows and their qualifications remain in
their own archives. See the
[new warmup-recording control](open-sweep-scan-native-kernel-single-warmup-recording-v4.json)
and `/tmp/libhft-warmup-rerun-20260909-gKFRZk/dotnet-native-kernel-single-review.json`.
Other earlier rows were not measured with this correction and are not relabelled.

The newly merged Rust v4 client also skips warmup folding and sample stores;
that separate path has not been corrected or validated by this C++/.NET change.
Neither `cargo` nor `rustc` is available in this SCAN session's PATH. Its existing
HP observations retain their original provenance, and no claim of complete
cross-flavour warmup parity is made yet.

## Native pool worker role-name inheritance — 2026-09-09

The fresh .NET Native/kernel POOL completed at **22:12:54 UTC**, with all
1,920,000 measured and 1,920,000 warmup offers completed. All 24 phase footers
drained without shedding, refused sends or outstanding requests; all 192 native
session/phase health records show LoggedOn and zero errors/event-ring drops.
Independent replay checks four raw files, all 288 series, zero drops/clamps and
exact response = service + scheduler. The 32 sessions are **27 PASS, 5 WARN**,
all warnings caused by p99 run CV (10.7007–16.3026%, below the 25% FAIL gate).
The row stays partial: service **34.278 / 39.902 / 46.206 / 105.988 µs**;
response **37.097 / 46.896 / 53.190 / 112.004 µs**. The target is exactly
50,000/s aggregate, 1,562.5/session/s, not the legacy integer CLI's 1,562.

**Its live placement audit is not clean:** 11 VIOLATION and 10 INCONCLUSIVE
samples, no PASS. The retained host snapshot identifies coordinator TID 186763
on core 19, workers 186764–186767 on 10–13 and control 187598 on 0–9. However,
all four workers have the coordinator's OS name `hft-pool-coord`. Linux children
inherit that name, so the audit correctly detects ambiguous role identities;
its later “actual-mask” and “intruder” messages are consequences of choosing
among duplicate names, not evidence that worker and coordinator shared a core.
This one snapshot does not establish uninterrupted placement.

The shared C++ `fix::AcceptorThreadPool::WorkerLoop` now sets and reads back
`hft-pool-worker` before reporting placement, adopting a descriptor or invoking
the worker callback. A failed set/readback/mismatch stops the pool and returns
failure; there is no new operation in the hot loop. JNI and .NET Native both
use this worker entry. The auditor's duplicate-role rejection is unchanged.
The actual Linux four-worker regression reproduces the failure before the fix,
then checks distinct parent/worker names and unchanged affinities; injected
set/get/mismatch tests verify failure before callbacks.
The optimized and ASan/UBSan Linux pool tests pass (including leak detection),
as do all 23 placement fixtures, 147 protocol checks and 27 handbook tests.

The new native-library rebuild and installation completed from `5e011904`
(including HP's `f5cd6779` busy-poll control, left off on SCAN). C++ finished
22:21:21, .NET 22:22:22, Java 22:22:31 UTC; all source/configuration guards
passed. Final host-side verification covers 88 comparisons, 48 installed files
and 61 permission paths without errors; evidence is
`/tmp/libhft-pool-role-build-20260909-cJfKtd/stage-verification-final.json`.
Do not call the earlier retained run a live-audit pass, or attribute
its p99 variance to name inheritance. See the
[qualified pool archive](open-sweep-scan-native-kernel-pool-role-identity-v4.json),
`/tmp/libhft-warmup-rerun-20260909-gKFRZk/kernel-pool-live-thread-snapshot.txt`
and `dotnet-native-kernel-pool-review.json` in the same evidence directory.

The **22:26:51 UTC correction rerun** now retains **11 live-audit PASS,
10 INCONCLUSIVE, zero VIOLATION/INVALID**. A timestamped actual task snapshot
binds coordinator 228618 to core 19, workers 228619–228622 to 10–13 with the new
`hft-pool-worker` name, and control 229366 to 0–9. The regression and live
observations validate the identity correction; they are not continuous
placement proof. All 1,920,000 measured and 1,920,000 warmup offers completed,
24 phases fully drained, 192 native health records clean. Four raw files/288
series replay exactly, with no drops/clamps and response = service + scheduler.

It still stays **partial**: 29 sessions PASS, two p99 WARN and CLIENT32
(process 3, local session 1) p50 FAIL, CV **14.8875%** above the unchanged 10% gate.
The row's service p50/p99/p99.9/max is **32.477 / 48.961 / 53.078 / 91.695 µs**;
response is **40.844 / 56.999 / 62.777 / 104.814 µs**. The two p99 warning
CVs are 14.6468% and 11.3449%; no delivery or saturation failure is hidden.

CLIENT32's raw distribution has persistent modes near 23 and 32 µs. Its median
changes mode as the faster population crosses 50%, while p99 barely moves:

| Run | Service p50 µs | Service p99 µs | Replies below 28 µs |
| --- | ---: | ---: | ---: |
| 1 | 31.786 | 34.065 | 35.785% |
| 2 | 24.263 | 34.168 | 51.690% |
| 3 | 31.850 | 34.112 | 44.460% |

The two populations occur throughout ten consecutive 2,000-reply bins, not
only in an early burst. The 28 µs split is descriptive, not a new gate. This
explains the reported median CV mechanically, but does not identify the cause
of the modes: no GC/JIT/NIC event correlation was captured. No first samples
were discarded and no thresholds or runtime window were changed. See the
[correction archive](open-sweep-scan-native-kernel-pool-worker-name-correction-v4.json)
and `/tmp/libhft-pool-role-rerun-20260909-rxWvMw/median-modes.json` alongside
the full raw review and actual task snapshot. Prior results remain archived.

## .NET Native/VMA pool warmup stall — 2026-09-09

The next canonical pool attempt terminated at **22:33:28 UTC** without any
measured samples. Clients 1–3 each sent 4,096 warmup requests, received **zero**
replies and timed out with 4,096 outstanding and 25,000 cap-shed offers. Client 4
sent/completed 85,333 and shed 74,667, then failed prepared-phase admission
because the other clients had aborted. All native status records still say
LoggedOn with zero step errors and event-ring drops: those counters do not
establish end-to-end progress. No measured epoch was released.

The parameter audit refuses the aborted v4 phase evidence, so the driver
correctly publishes an interrupted attempt, not a new latency row. Its generic
“parameter audit failed” error is downstream of the real warmup timeout,
not evidence of a malformed launch rate. The earlier VMA/pool latency row is
unchanged and must not be read as a result of this attempt. The live watcher
retains two PASS and six INCONCLUSIVE samples, no VIOLATION: worker identity
is corrected, but the warmup stall remains. No process was left running.

This resembles the previously retained managed/VMA mono failure (first three
clients stall, fourth progresses), but shared causation is not established.
No timeout, cap, schedule or VMA polling setting was relaxed. The current
production native build is `5e011904`; harness/source snapshot is `559e84f9`.
See the [failed attempt archive](open-sweep-scan-native-vma-pool-warmup-failure-v4.json)
and `/tmp/libhft-pool-role-rerun-20260909-rxWvMw/dotnet-native-vma-pool/`.

## Managed VMA polling control

The failed managed VMA mono rerun at 21:13 UTC remains a real warmup failure:
client indices 0–2 each sent 4,096 requests without a reply; client 3 drained its
99,700 actual sends. No measured row from that attempt was published. The earlier
successful matrix row is historical, not evidence that the new attempt passed.

Two separate nonpublishing probes then compared client `VMA_RX_POLL=10` and
explicit `-1`, without changing the installed managed binary, server's `-1`
policy, 32-session topology, 50,000/s aggregate rate, 20,000 warmup and measured
iterations per session, three runs, or the two-second stall watchdog. Both used
source commit `0bb423f4f9b298eb067dbbe352ee7093ae151f6a`; no source/install drift or
remaining FIX processes were reported at their completion boundaries.

| Client receive-poll setting | Completion UTC | Measured replies | First-warmup shed offers |
| --- | --- | --- | --- |
| `10` | 21:42:10 | 1,920,000 / 1,920,000 | 68,192 |
| `-1` | 21:49:57 | 1,920,000 / 1,920,000 | 53,863 |

Each probe retained all 24 client phase footers. Every actual send drained;
measured phases and later warmups have no shedding, refused sends or outstanding
requests. **Neither setting reproduced the stall.** One sequential pair with
different fresh ports is not a randomized experiment, a general capacity claim,
or evidence that bounded polling fixes this intermittent failure. Normal polling
defaults remain unchanged. These explicitly diagnostic measurements are not
imported into the canonical matrix, and do not erase the failed attempt.

Both manifests, transcripts, raw files, placement observations and terminal
records remain under
`/home/yann/libhft-bench-runs/managed-vma-rx-poll-draft-20260908-1GeEWu/`, in
`poll10-first` and `pollminus1-control`. The subsequent HP merge occurred only
after both probes were terminal; its changed source files are not run-time drift.

The managed server review separately reproduced a socket-lifetime defect in
mono, pool and thread-per-session: a retired peer stayed transport-open until
all siblings ended. The correction disposes that peer immediately and captures
any cleanup error separately from its serving error. `Peer.Dispose` uses a
`finally` block so optional dump-flush failure cannot skip socket disposal.
Cold reports distinguish retirement from health and expose existing whole-session
seen counters, which are neither measured-only counts nor successful reply counts.
An `IOException` is not relabeled as proven FIN. Ordinary serving/fault policies
remain unchanged; mono/pool cleanup failure returns nonzero after siblings finish,
while the legacy thread-per-session cleanup exit policy remains explicitly
reported rather than silently redefined.

All 200 MultiClient tests pass, including 12 durable retirement cases. Tests
exercise actual serving methods with two loopback peers, same-worker and
different-worker pool cases, protocol faults, and a test-owned FIFO that makes
one peer's real dump flush fail while the healthy peer finishes three replies.
Five original-source cases reproduce delayed closure. Evidence:
`/home/yann/libhft-bench-runs/managed-retirement-tests-20260908-Om5Ihp/` and
`/home/yann/libhft-bench-runs/managed-retired-peer-all-models-draft-20260908-hEU9Ny/`.
The production managed build is now staged and verified; its remeasurement is
recorded below.
The failed VMA capture lacks
this per-peer evidence, so these tests do not prove the cause of its missing ERs.

The new canonical .NET Pure / VMA / mono sitting completed at 22:37:43 UTC:
32/32 sessions, all 1,920,000 measured replies, and all 32 service stability
checks PASS. Service p50/p99/p99.9/max is 20.658/24.991/25.255/51.551 µs;
response is 21.115/26.601/27.184/54.246 µs. It replaces the older observation
as `ok`; the prior failed attempt remains archived separately. All 24 phase
footers drained without send refusals or outstanding requests. First warmup
shed 64,904 offers (processes one through four: 12,806/13,540/13,665/24,893);
warmup actually sent and completed 1,855,096 requests across the three runs.
No measured offers were shed. Warmup shedding is permitted by the unchanged
contract when every actual send drains; it is not hidden as zero.

All 32 new cold retirement records report socket_closed=true and no cleanup
error, with one Logon seen per peer. Summed new_orders_seen is 3,775,096,
matching all actual warmup plus measured sends, not planned slots. The observed
retirement exception is IOException; neither that type nor the summary's
retirement count proves FIN or measured success. The footer explicitly retains
health=not_assessed. Independent raw validation reproduces all service classes
and all 288 complete raw series with no drops/clamps and exact
response = service + scheduler delay. Direct argument bindings, 52 inventoried
installed hashes and six selected source hashes match. The watcher records
14 PASS / seven INCONCLUSIVE / no VIOLATION; placement is sampled, not continuous.
See [the canonical archive](open-sweep-scan-managed-vma-mono-correction-v4.json)
and `/home/yann/libhft-bench-runs/socketxtreme-corrections-rerun-20260908-QpGmMq/dotnet-managed-vma-mono-independent-review.json`.
This successful repetition validates delivery and cleanup on the new build;
it does not establish the cause of the earlier missing-ER failure.

## SocketXtreme shared-ring correction

HP's `1d20a44d` fixes a drainer that refused to poll while it had unread own
completions, starving its fed peers. The integrated change also introduced an
unconditional held-borrow guard. An existing socket-free test reproduced that
regression: after a partial `ReadMsg`, `PollAndRoute` returned idle instead of
observing the next negative ring poll. The borrowed bytes live in VMA payload
memory or the separate gather buffer, with their ownership descriptor copied to
`m_heldPacket`; they do not point into the compacted completion queue.

The follow-up removes only that held-borrow guard and corrects the lifetime
comment, preserving HP's append/compaction logic and queue-capacity checks.
Fourteen regression groups now cover pending-own completion progress, scalar and
gather borrows, partial copy reads, capacity backpressure, poll-error propagation
and exact packet release. GCC 14 optimized and ASan/UBSan runs pass; existing move
and 32 accept-ownership checks also pass. Both the pre-HP starvation and the new
held-borrow regression fail their respective negative controls.

Evidence: `/home/yann/libhft-bench-runs/vma-drainer-regression-20260908-3tS8yp/`.
These execute real transport logic against inert socket/API fixtures, not a live
NIC. Matching C++ SocketXtreme, JNI and .NET production builds completed at
22:08:29/22:09:36/22:09:31 UTC from
`0de7a00fb7bde2589af2171e6e64ac485a409689` and are now installed. Source/config
manifests remain unchanged across each build; post-install verification matches
all 47 in-scope files, native aliases and root-owned permissions. Evidence:
`/home/yann/libhft-bench-runs/shared-fixes-build-20260908-O9hRop/`.
The existing QuickFIX/J adapter extra is retained unchanged. C++ kernel/TCPDirect
and Rust were not rebuilt in this operation. The first fresh canonical result,
Java/JNI / SocketXtreme / mono, completed at 22:15:26 UTC with 32/32 sessions.
Service p50/p99/p99.9/max is 12.698/19.516/22.353/79.293 µs; it remains
`partial` for latency instability. Its [separate archive](open-sweep-scan-drainer-java-jni-mono-v4.json)
preserves the new result; historical failures are not reclassified by this success.
All 24 phase footers drained completely, with 1,920,000 measured replies and
no phase shedding, refused sends or outstanding requests. The watcher retained
24 complete samples: 17 PASS and seven no-application INCONCLUSIVE, with no
VIOLATION or unfinished sample. Eleven PASS snapshots include all five processes
with server10, clients11/12/13/15 and VMA maintenance14. No retained joint
wall/monotonic calibration supports an exact phase-overlap or continuous-placement
claim. Full delivery and sampled placement do not remove the latency qualification.
Raw replay reproduces all session latency summaries and stability classes:
19 PASS, 12 WARN and one FAIL. Every WARN has service p99 CV above 10%.
The failing session C3S8 has service p50 runs 12.353/14.139/11.602 µs,
CV 10.2631%, exceeding the unchanged 10% failure boundary; its p99 CV is also
13.7764%. This is a real run-to-run qualification, not a missing-reply or
classifier discrepancy. All 288 raw series retain 1,920,000 samples per probe,
with no dropped/clamped samples and response = service + scheduler delay.
The independent replay is retained in
`/home/yann/libhft-bench-runs/socketxtreme-corrections-rerun-20260908-QpGmMq/java-jni-sx-mono-independent-review.json`.
.NET Native / SocketXtreme / mono then completed at 22:23:33 UTC with 32/32
sessions: service p50/p99/p99.9/max 12.343/19.484/23.277/189.144 µs and response
13.712/21.076/24.943/190.981 µs. Its [separate archive](open-sweep-scan-drainer-dotnet-native-mono-v4.json)
retains this new observation. All 24 phase footers fully drained, delivering
1,920,000 warmup and 1,920,000 measured replies with no shedding, refused sends
or outstanding requests. All 192 native per-session phase records report
LoggedOn, no step/session errors and no raw FIX drops; this emitter does not
report a stale-reply count, so no zero-stale assertion is made.

The independent raw replay reproduces all 32 service classifications: 10 PASS,
22 WARN, no FAIL. Twenty-one sessions exceed the 10% service p99 CV warning
limit (maximum 21.4347%, below the 25% failure limit). Two exceed the 5% service
p50 CV warning limit: CLIENT21 at 9.3313% and CLIENT42 at 8.8800%; CLIENT42 also
has a p99 warning. No session has a p99.9 warning. All 288 raw series preserve
1,920,000 samples per probe, with no drops/clamps and response = service +
scheduler delay. Direct raw-file launcher bindings, all 52 captured installed
file hashes and seven selected native/reporting source hashes match. These
52 files include retained extras, not 52 newly built artifacts. The watcher
records 15 PASS and eight INCONCLUSIVE samples, with no VIOLATION; discrete
samples do not establish continuous placement. Thus `partial` remains a
warning-level run-to-run latency qualification, not incomplete delivery.
Replay evidence: `/home/yann/libhft-bench-runs/socketxtreme-corrections-rerun-20260908-QpGmMq/dotnet-native-sx-mono-independent-review.json`.
C++ / SocketXtreme / mono completed at 22:32:41 UTC with 32/32 sessions:
service 13.141/22.480/25.107/71.658 µs and response
13.780/23.199/25.749/72.243 µs (p50/p99/p99.9/max). All 24 phase footers
fully drained, with 1,920,000 warmup and 1,920,000 measured replies, no shedding,
refused sends, outstanding requests or measured deficit. All 288 raw series
retain the full sample counts, with no drops/clamps and response = service +
scheduler delay; direct raw-file argument bindings, all 52 inventoried installed
hashes and six selected source hashes match. Its emitter does not disclose a
stale-reply count. The watcher records 15 PASS and seven INCONCLUSIVE samples,
with no VIOLATION; these remain discrete observations.

Raw reconstruction reproduces 31 PASS / no WARN / one FAIL session. CLIENT48
(process four, local session seven) has service p50 runs
15.061/12.305/12.056 µs, CV 12.6912%, above the unchanged 10% failure boundary.
Its p99 CV is also warning-level at 13.6267%; p99.9 CV is 6.5814%, below warning.
The cell therefore remains `partial`, despite full delivery. Retained
[canonical result](open-sweep-scan-drainer-cpp-mono-v4.json) and independent
replay `/home/yann/libhft-bench-runs/socketxtreme-corrections-rerun-20260908-QpGmMq/cpp-sx-mono-independent-review.json`
preserve the qualification. All three native-backed SocketXtreme mono reruns
have now completed successfully at the delivery level; this does not establish
that every intermittent stall is eliminated or that every session is stable.

## Corrected C++/VMA shard rerun

The new explicit-EOF legacy acceptor completed at 21:02:31 UTC with all 32
sessions and all 1,920,000 measured replies. All 24 client phase footers drained,
with no shedding, refused sends or outstanding requests. Its qualification is
23 PASS / 9 WARN / 0 FAIL sessions, not missing replies. Service p50/p99/p99.9/max
is 10.136/30.794/41.055/68.851 µs. The separate watcher retained 15 PASS and seven
no-application INCONCLUSIVE samples, with no VIOLATION. Discrete observations
do not prove uninterrupted placement.

The old stalled warmup remains preserved. The regression establishes the idle
read/EOF defect and the new run establishes successful delivery; neither proves
that this was the sole cause of the old stall. See
[the new result archive](open-sweep-scan-provider-corrections-shard-v4.json).