fix(qwp): prevent JVM crash when closing a QWP sender

[jerrinot]

Closing a QWP sender (on shutdown, reconnect, or sender churn) could
crash the entire JVM with a SIGSEGV when it raced the background segment
manager. Under load this showed up as rare, hard-to-reproduce process
deaths.

implementation details for reviewers
Two native-memory races are fixed:

1. Watermark SIGSEGV. The worker services rings off a snapshot taken
   under lock, then writes the acked-FSN watermark outside the lock. If a
   sender unmapped that file in the same window, the worker wrote through a
   dangling address → SIGSEGV. Fix: the watermark write + totalBytes
   accounting now run under lock, gated on a lock-guarded
   RingEntry.registered flag that deregister() clears before close()
   unmaps.

2. pathScratch use-after-free. close() uses a bounded join; a
   timed-out join could leave the worker alive while its scratch buffer was
   freed. Fix: only free worker-owned native state once the worker is
   observed dead, else retry on a later close().

[mtopolnik]

[PR Coverage check]

😍 pass : 42 / 43 (97.67%)

file detail

	path	covered line	new line	coverage
🔵	io/questdb/client/cutlass/qwp/client/sf/cursor/SegmentManager.java	38	39	97.44%
🔵	io/questdb/client/cutlass/qwp/client/sf/cursor/CursorSendEngine.java	4	4	100.00%

[bluestreak01]

Approving after a full level-3 adversarial review.

This is a correct, well-tested fix for two real pre-existing native-memory use-after-free hazards, both reachable in the production owned-manager path when the bounded join(5s) times out under load:

1. Watermark write-through-unmapped: the worker's watermark.write() now runs inside synchronized(lock) gated on the new RingEntry.registered flag, which deregister() flips false under the same lock before the engine unmaps the watermark. This correctly routes around AckWatermark's non-volatile 'closed' boolean (the original bug) by supplying a lock happens-before edge.
2. pathScratch use-after-free: close() now early-returns on t.isAlive() without freeing worker-owned native scratch, trading a bounded ~256B leak for not freeing memory a live worker still writes.

Verified against source: drainTrimmable() and SegmentRing.close() are both synchronized(this) (clean ownership transfer, no double-free); needsHotSpare()/nextSeqHint() read only heap state (stale snapshots never touch freed native memory); register() reordered so nothing throwable runs after rings.add (no half-registered entry); totalBytes accounting cannot drift under any deregister/trim interleaving. All production callers (CursorSendEngine.close, QwpWebSocketSender, BackgroundDrainer, Sender, reconnect loop) walked and SAFE. Touched + surrounding test suite is green (26/26 plus the full sf.cursor.* package), and the crash-capable regressions confirm both fixed branches actually fire.

Non-blocking follow-ups (optional):

• close() called from an already-interrupted thread always early-returns and leaks pathScratch regardless of worker/disk health (SegmentManager.java:160-176). Strictly safer than the prior crash; consider clearing interrupt status or a non-interruptible bounded wait so a clean stop is still attempted.
• 'a later close() retries' overstates production reality (engine closes the owned manager exactly once); tighten the comment.
• Shared-manager ctor catch never deregisters; safe only because register() can't throw after rings.add — a maintenance hazard worth the existing invariant comment.
• Test gaps: no e2e production timed-out-join through engine close; ctor-catch reorder intent effectively untested; watermark test is crash-only signal; two ctor-failure tests lack @test(timeout).