Add `ShardWriter::delete_no_wait`, the delete analog of `put_no_wait`: it
inserts the tombstone into the in-memory tier (visible to reads on this writer
the instant it returns) and hands back the durability watcher *without*
awaiting it, so a caller can hold an external lock across only the in-memory
insert and await durability after releasing it. `delete` becomes a thin
wrapper that awaits the watcher.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

…ntee

The CI test `test_shard_writer_delete_no_wait_visible_before_durability`
read through the index-driven LSM scan *before* awaiting the durability
watcher and asserted the tombstone was already folded out. But the
no-wait path appends the tombstone to the batch store synchronously and
defers both the PK-index update and the `max_visible_batch_position`
advance to the async WAL flush — which is exactly what awaiting the
watcher waits for. The LSM read is gated on that watermark, so the
tombstone cannot be folded until the flush lands. The test encoded a
guarantee the system does not make and lost the race deterministically
in CI.

Replace it with two tests for the actual contract:
- durable: tombstone is in the in-memory tier immediately (batch-store
  `row_count`), watcher returned without blocking, and the LSM read
  folds the delete only after `watcher.wait()`.
- non-durable: no watcher is returned, but the tombstone still lands in
  the in-memory tier.

Also correct the `delete_no_wait`/`put_no_wait` doc comments, which
overclaimed immediate "visible to reads on this writer" — true only at
the batch-store level, not the index-driven LSM read path.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>