fix(rollout): stop swallowing failures in RolloutStore's detached close

[beinan]

Closes #185 — though not in the way the issue described. See below.

The reported bug does not exist

#185 claimed the flush sweeper's LRU-only coverage could leave an evicted store's rows permanently invisible. That is wrong, and I should have verified before filing it.

ShardWriter::close() explicitly freezes the active memtable and waits for the flush (lance-7.0.0 dataset/mem_wal/write.rs:1911-1921), and RolloutStore::Drop spawns a detached close. So dropping an evicted handle does seal its rows. Confirmed by probe and now by a test in this PR:

dropping_a_store_seals_its_unflushed_rows ... ok

The real (smaller) problem

That safety net is entirely silent:

if let Ok(writer) = Arc::try_unwrap(writer) {
    let _ = writer.close().await;
}

Three distinct ways it can fail to seal, none observable:

1. close() returns Err — discarded by let _ =
2. Arc::try_unwrap fails because an in-flight append still shares the writer — the if let Ok silently skips
3. No Tokio runtime is available — the outer if let Ok(handle) silently skips, nothing is spawned

In each case rows stay durable in the WAL but invisible until the next restart replays it. Debugging that from the outside means staring at a store that accepted writes and returns no rows, with nothing in the logs.

Change

Log all three (warn / debug / warn respectively). No behavior change — best-effort stays best-effort.

Also documents the eviction guarantee on AppState::rollout_stores: the sweeper's resident-only scan looks like a gap on inspection, and the reason it isn't was not written down.

Testing

New dropping_a_store_seals_its_unflushed_rows adds a row, drops the handle without flush or close, and polls a fresh reader until the row appears. This is the invariant #185 doubted; now it is enforced.

cargo test -p lance-context-core --lib → 162 passed, 0 failed. fmt + clippy clean.

🤖 Generated with Claude Code