Failed Open on torn free-list leaks FileShare.None handle after Dispose

[KarataevDmitry]

Context

Consumer: CDP MCP / CascadeIDE intent-workspace seat DB (EF Core OutWit.Database.EntityFramework 1.0.3).

Bug

When Open fails with torn free-list / ArgumentOutOfRangeException: Page number … out of range (FreePage ≥ TotalPageCount after kill/remount pressure), the process often keeps an exclusive FileShare.None handle after the failed open/Dispose.

Subsequent opens then fail with IOException: … being used by another process within ~50ms (no real contention), and quarantine/File.Move of the torn file also fails until the process is killed.

Expected

Failed Open must not leave a sticky exclusive OS handle. Dispose/failed Open path should release the file so callers can quarantine or reopen.

Repro sketch

1. Produce a large seat *.witdb with torn free-list (dual-seat/FileShare fights or abrupt Kill mid-write historically did this).
2. new DbContext(...UseWitDb...).Database open / EnsureCreated → pageNumber OOR.
3. Immediately retry Open or File.Move of the same path → being used by another process while no other process holds the file.
4. GC + sleep sometimes insufficient; process Kill clears the leak.

Impact

Forced us to leave WitDB for seat storage (migrating to SQLite). Filing so the engine can fix handle lifetime on failed Open.

[KarataevDmitry]

Update from consumer: author confirmed fixes landed. We upgraded OutWit.Database.EntityFramework 1.0.3 → 12.2.0 in CDP MCP / CascadeIDE and aborted the SQLite cutover. Will dogfood remount/kill pressure on 12.2.0; feel free to close if this matches your release notes.

[KarataevDmitry]

Dogfood re-verify on 12.2.0 against our lived torn seat bak (intent-workspace.witdb.torn-manual-…, ~434MB):

1. Deep open still throws ArgumentOutOfRangeException pageNumber OOR (corrupt free-list bytes remain — expected for old torn file).
2. After Dispose, immediate File.Move succeeds in ~1ms — no sticky being used by another process. On 1.0.3 this was the hard wall.
3. Fresh durable roundtrip: EF Where(StageId == guid) server count == client count (5/5) — GUID filter issue looks fixed.

Verdict for our cockpit path: handle-leak gone; quarantine/heal can land again. Thanks.