The native device requires the Spectre-mitigated CRT libs; when the CMake
Visual Studio generator defaults to a newer toolset than the one whose Spectre
libs are installed (common with VS 2026 Insiders), configure/link fails. Pass
`-T v143` (or the matching toolset) to select it explicitly.

Co-authored-by: Copilot <[email protected]>

Independent module-by-module review (two code-review passes + a peer) surfaced
several latent defects beyond the original hang fix. Addressed:

io_uring (blocker + high):
- io_uring_submit() returns the count of ALL flushed SQEs, not "1 for this op".
  A stale no-op SQE (left by a prior failed-submit/unwind or Wake) made a later
  submit return 2; the `res == 1` check then treated success as failure and
  freed an io_context whose op was already in flight -> use-after-free on
  completion. Treat `res >= 1` as success (our SQE is the last prepared, so any
  flush includes it); `res < 1` rewrites the prepared SQE to a no-op and frees.
  Same fix applied to UringIoHandler::Wake.
- The uring submit loop spun in-epoch indefinitely on -EAGAIN/-EBUSY. It now
  yields a bounded budget then unwinds (Status::Pending) like the get_sqe/libaio
  paths, so the epoch/thread-id slot is never held across a long wait.
- UringIoHandler::pick_ring() cached a thread_local ring index without the
  owner+bounds guard QueueIoHandler::pick_context() has, so a thread that used a
  uring device with more rings then one with fewer read out of bounds. Mirrored
  the libaio guard.

Managed (high + medium):
- Reset/RemoveSegment/GetFileSize/TryComplete captured the native handle without
  the numPending lease ReadAsync/WriteAsync use, so a concurrent Dispose() could
  free it mid-call -> native use-after-free. They now lease numPending (with the
  disposedFlag fast-path) and decrement in finally. Removed the dead, misleading
  EnsureReadyOrSilent helper.
- Throttle() seeded effectiveThrottleLimit to MaxThrottle, so a cold-start burst
  before lazy device creation bypassed the configured throttle and flooded the
  just-sized ring. It now gates on the live clamped limit until the handle exists.

Cleanup:
- Deleted the dead reserving default Thread::ThreadId() ctor (would yield-spin
  forever if ever used; the only instance uses the explicit kInvalidId ctor).
- Unified the in-epoch submit yield budget to a single small constant (16) and
  removed the unused kMaxSubmitRetries.

Documented and deliberately NOT changed: SubmitWithEpoch holds the epoch across
log_.ReadAsync -> OpenSegment -> BumpCurrentEpoch (the standard FASTER protocol);
a self-deadlock needs 256 concurrent segment opens within one thread's microsecond
epoch region and is practically unreachable — and the unwind releases the epoch
more often than the original, reducing exposure.

Validation: 70/70 device tests; libaio/uring Device.benchmark NVMe storage-bound
0 validation errors at ~740K/738K ops/sec; KV.benchmark 100M storage-bound ~729K
ops/sec — no regression vs the pre-review build.

Note: the win-x64 native_device.dll is unaffected in behavior (the changes are
Linux-submit-path-only or dead-code removal; the shared-header edits are no-ops on
the IOCP path) but is built from slightly older source; rebuild for source parity.

Co-authored-by: Copilot <[email protected]>

… tests

GetFileSize() called log_.size() without acquiring the epoch, but size()
can lazily OpenSegment() whose bundle-expand path calls
epoch_->BumpCurrentEpoch(). BumpCurrentEpoch requires the calling thread to
hold epoch protection; on an unprotected thread ProtectAndDrain dereferences
an unreserved epoch-table slot and segfaults. This is reachable in production
(recovery, and any GetFileSize on a not-yet-open segment once another segment
is open, including after RemoveSegment/Truncate). A cold-device GetFileSize(0)
survived only because the first-ever OpenSegment takes a no-bump path.

Fix: wrap GetFileSize in EpochGuard, exactly like RemoveSegment / Read / Write.
The change is in the shared header, so it applies to all platforms; the
Linux .so are rebuilt here and the Windows DLL must be rebuilt to pick it up.

Tests (test.hlog/DeviceTests.cs): add coverage that previously had none —
- both IO backends (libaio + io_uring) round-trip and parallel reads;
- multi-completion-thread / multi-io_context sharding;
- multiple devices with different shard counts driven from many threads
  (regression for the pick_context/pick_ring owner+bounds guard);
- throttle -> submission-ring sizing and throttle-above-MaxThrottle clamping;
- high submitter concurrency (64 threads) as a direct regression for the
  original production hang (slot-exhaustion / in-epoch full-ring spin);
- late P/Invoke entry points GetFileSize / Reset / TryComplete / RemoveSegment.
The RemoveSegment + GetFileSize-after-remove test is what surfaced the crash
fixed above.

Co-authored-by: Copilot <[email protected]>