feat(agent): single-writer lock, read-only open, recoverable WAL

- HDF5Memory::create/open take an exclusive advisory lock on <store>.h5.lock
  (std File::try_lock, no new dependency). The store lives in memory and is
  rewritten wholesale at each checkpoint, so two handles on one store used to
  silently destroy each other's data; a second writer now gets
  MemoryError::Locked. The OS drops the lock with the descriptor, so a crash
  never leaves a stale lock. Acquisition retries for ~250 ms to absorb a
  previous owner that is mid-teardown; AsyncHDF5Memory::shutdown releases the
  lock once its writer task has stopped.
- HDF5Memory::open_read_only: a lock-free, point-in-time view (checkpoint +
  current WAL contents, replayed in memory) that never writes — it does not
  repair, upgrade or move the WAL, and anything that would persist returns an
  error. The CLI's recall/stats/agents-md/export use it, so a store can be
  inspected while an agent has it open. Tests that reopened a store purely to
  verify on-disk state now use it.
- open() no longer fails on a WAL that cannot possibly be replayed (torn
  header, bad magic): it is moved to <store>.h5.wal.corrupt-<ts>, reported via
  HDF5Memory::quarantined_wal(), and the healthy .h5 opens from its last
  checkpoint. A well-formed header with an unknown version still fails and is
  left untouched — most likely a newer build's WAL, which must not be
  discarded.

Co-Authored-By: Claude Fable 5.1 <[email protected]>

crates/clawhdf5-agent/src/wal.rs

@@ -135,6 +135,45 @@ pub struct WalFile {
     chain_len: u64,
 }
 
+/// What a WAL file's 9-byte header looks like, without reading any entries.
+#[derive(Debug, Clone, Copy, PartialEq, Eq)]
+pub enum WalHeaderStatus {
+    /// A version this build can read (current or legacy).
+    Readable,
+    /// Shorter than a header — e.g. a crash while the file was being created.
+    /// It cannot contain entries.
+    Torn,
+    /// Not a WAL file at all.
+    BadMagic,
+    /// Well-formed header from a version this build doesn't know — most
+    /// likely written by a *newer* build. Never discard this: the entries are
+    /// probably fine, this binary just can't read them.
+    UnknownVersion(u8),
+}
+
+/// Classify the header of the WAL at `path`.
+pub fn wal_header_status(path: &Path) -> std::io::Result<WalHeaderStatus> {
+    let mut header = [0u8; WAL_HEADER_LEN as usize];
+    let mut f = File::open(path)?;
+    let mut filled = 0;
+    while filled < header.len() {
+        match f.read(&mut header[filled..])? {
+            0 => return Ok(WalHeaderStatus::Torn),
+            n => filled += n,
+        }
+    }
+    if header[0..4] != WAL_MAGIC {
+        return Ok(WalHeaderStatus::BadMagic);
+    }
+    Ok(match header[4] {
+        WAL_VERSION
+        | WAL_VERSION_CHAINED_NO_UPDATE
+        | WAL_VERSION_CRC_UNCHAINED
+        | WAL_VERSION_LEGACY_NO_CRC => WalHeaderStatus::Readable,
+        v => WalHeaderStatus::UnknownVersion(v),
+    })
+}
+
 /// A position in a WAL's CRC chain: `len` bytes of entries after the header,
 /// whose chained CRC is `crc`.
 ///