test(storage): close project catalogs before cleanup

[liugddx]

Summary

• track every ProjectCatalog opened by the project-catalog test suite
• close catalogs in reverse order before deleting the temporary root that owns their runtime.sqlite lease
• preserve explicit close calls while making cleanup deterministic on Windows

Part of #2142 Phase 1.

Why

The latest Windows baseline reports 16 project-catalog.test.ts failures at temporary-root cleanup. All 16 tests complete their assertions and then hit EBUSY because an open catalog still owns runtime.sqlite or its WAL/SHM files. The two tests in the same suite that explicitly close both catalogs already pass on Windows. This fixes fixture lifecycle ordering without adding filesystem retries or changing production behavior.

Validation

• npm run build:test
• node --test packages/storage/dist/__tests__/project-catalog.test.js (20 pass)
• npx biome check packages/storage/src/__tests__/project-catalog.test.ts
• git diff --check

[liugddx]

Windows baseline confirms the intended effect. Storage moved from the prior 648 pass / 38 fail / 38 skip to 664 pass / 22 fail / 38 skip: exactly 16 failures were eliminated, and the artifact contains no remaining project-catalog cleanup failures. The lane remains non-blocking because unrelated Windows failures are still recorded.

[liugddx]

@Astro-Han

[Astro-Han]

Thanks — the fix is correct and sufficient on all adversarial angles we checked. All 24 createProjectCatalog calls route through the shadowed helper (the only escape, a direct create inside a child process, exits before rm runs), double-close is unreachable behind the wrapper map-delete → lease released flag → refs==0 owner-close chain, and DatabaseSync.close() → sqlite3_close_v2 releases the -wal/-shm handles on last-connection close, which matches your two already-passing Windows tests. 20/20 green locally.

Three optional nits:

• The close loop in the rm cleanup (test:43-52) has no try/catch — a throwing close would skip the remaining closes and the remove. Unreachable today (close only throws on already-closed, which the three layers prevent), but a try { close() } catch {} would make the invariant airtight.
• isAbsolute(fromRemovedRoot) at :51 is dead code (relative() never returns absolute), and the reverse-order close is unnecessary given refcounted closing.
• An afterEach closing all tracked catalogs would be equivalent and simpler here (all tests are try/finally with no nesting) — worth considering if you ever touch this file again.

Approving.