DictStore: a multi-chunk external leaf can be read across a concurrent overwrite, mixing two generations

Overwriting an external `DictStore` leaf while another process reads it can hand that reader an array assembled from two different generations of the value. No error is raised and the data is not corrupt — the array simply never existed as a stored value.

### Cause

The handle `DictStore.__getitem__` returns holds no file descriptor. The C layer re-opens the leaf **by path** for every chunk it decompresses, so one `arr[:]` over an N-chunk leaf is N independent opens. A concurrent `__setitem__` on the same key swaps a new leaf into place between two of those opens, and the read takes its low chunks from the old file and its high chunks from the new one.

This is the layer underneath #692. That one was about readers hitting a *partial* file and failing with `RuntimeError: Error while getting the buffer`; the fix (build the leaf beside its final name, `os.replace()` it in) made every file a reader can open complete. Chunks now decompress correctly — but not necessarily all from the same generation.

### Reproducer

A 40-chunk leaf, one reader handle, a writer process atomically replacing the file in a loop. Each generation `i` is `np.full(N, i)`, so any mix is visible as more than one distinct value:

```python
N, CHUNK = 4_000_000, 100_000
blosc2.asarray(np.full(N, 0, dtype=np.int64), chunks=(CHUNK,), urlpath=path, mode="w")
handle = blosc2.open(path, mode="r")
# writer process, in a loop:
# blosc2.asarray(np.full(N, i, dtype=np.int64), chunks=(CHUNK,), urlpath=tmp, mode="w")
# os.replace(tmp, path)
data = handle[:]
assert len(np.unique(data)) == 1 # fails
```

Result on an M4 Pro (macOS, blosc2 4.10.1.dev0):

```
TORN on read 27: generations [34 35] ... (2 distinct)
reads=249 torn=38 runtime_errors=0
```

**38 of 249 reads** straddled a swap. `runtime_errors=0` confirms the atomic replace is working; this is a separate failure mode.

### Scope

- Needs a concurrent overwrite of the same key — a write-then-read store never sees it.
- **Single-chunk leaves are immune** (one open per read). That is why `test_dict_store_read_during_overwrite` never caught it: its leaf is 800 bytes.
- Scales the wrong way: the bigger the leaf, the more opens per read and the wider the window.

### Possible fixes

1. **Versioned leaf names** (`hot..b2nd`): an overwrite writes a new path, and the reader keeps reading the generation it resolved under the lock. The real fix — MVCC in effect — at the cost of a reclamation story for stale versions.
2. **Hold the store lock across the whole read**: `__getitem__` could no longer return a lazy handle; callers would need a context manager or a read-into-memory API.

Documented as an accepted race for now (`DictStore` docstring and the "Sharing Containers Across Processes" guide), with `holding_lock()` around a copy-out as the workaround.

Bắt đầu với DictStore.__getitem__, đường dẫn đọc chunk ở lớp C và bài kiểm thử hiện có test_dict_store_read_during_overwrite; tái hiện trường hợp nhiều chunk được mô tả trong issue. Thay đổi được xem là hoàn tất khi các lần ghi đè đồng thời không còn khiến một lần đọc kết hợp các chunk từ các thế hệ khác nhau, đồng thời xem xét workaround locking đã được ghi chép và các hướng dẫn bị ảnh hưởng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.