clawhdf5: a dropped FileEditor releases its lock at once

FileEditor's flock belongs to the open file description. When another
thread forks to spawn a process, the child shares the locked descriptor
until it execs, so a reopen right after the drop could be refused with
Error::Locked (a one-off failure of edit_interop::editor_locks_the_file in
a parallel test run). Drop now unlocks before closing, which releases the
lock for every descriptor sharing it.

Reproducer edit_tests::drop_releases_the_lock_while_other_threads_spawn_processes
(4 threads running `true`, 2000 open/drop rounds): 1483 of 2000 reopens
refused before, 0 in 30 runs after (tank). An OFD lock would not help: it
is inherited across fork the same way and does not conflict with
libhdf5's flock. The agent store's lock file unlocks on drop too.

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

CHANGELOG.md

@@ -2,6 +2,19 @@
 
 ## Unreleased
 
+### A dropped `FileEditor` releases its lock at once (2026-09-28)
+- `FileEditor`'s `flock` could outlive the editor for a moment when
+  another thread forked to spawn a process: the child shared the locked
+  descriptor until it exec'd, so reopening the file right after the drop
+  was sometimes refused with `Error::Locked` (seen once as a failure of
+  `edit_interop::editor_locks_the_file` in a parallel test run). The drop
+  now unlocks before closing, which releases the lock for every descriptor
+  that shares it. Reproducer
+  `edit_tests::drop_releases_the_lock_while_other_threads_spawn_processes`
+  (tank, 2026-09-28): 1483 of 2000 reopens refused before, 0 in 30 runs
+  after. The agent store's lock file unlocks on drop the same way (its
+  250 ms retry on open had hidden the race). `docs/known-issues.md`.
+
 ### `ObjectHeader::parse` back at its pre-M2/M3 speed (2026-09-27)
 - Parsing a version-1 object header was 4% slower than before range-read
   M2/M3 (`docs/known-issues.md`). The cause was the call to the per-chunk