fix(db): avoid live WAL TRUNCATE after incremental reclaim

[Bl0ck154]

Summary

reclaimFreedPages() still ends an incremental cleanup pass with wal_checkpoint(TRUNCATE) even though #14005 removed live TRUNCATE from WAL maintenance because changing the live WAL geometry can invalidate mapped handles and crash with SIGBUS.

This switches the cleanup-path final checkpoint to PASSIVE. The periodic WAL maintenance path already owns WAL high-water management, while PASSIVE is enough to fold reclaimed pages back without mutating the live WAL file geometry.

Why

• fix(db): never TRUNCATE-checkpoint a live WAL (SIGBUS under traffic) #14005 explicitly establishes that live TRUNCATE is unsafe under concurrent handles.
• reclaimFreedPages.ts predates that change and still retained a live TRUNCATE call.
• The cleanup scheduler runs while the server is live, so it can overlap with other readers/handles.

Validation

• npx tsx --test tests/unit/db/cleanup-reclaim-freed-pages.test.ts
• 8/8 tests pass.
• The existing INCREMENTAL regression still confirms page_count shrinks after reclamation with a final PASSIVE checkpoint.

[diegosouzapw]

Thanks @Bl0ck154 — merging via the release merge-train. Validated in local merge-train (mt-train10c) on the devbox @ train tip 4d841aa1c740bbaa03868dc0a403c62099a99a42 with the 72 sibling PRs of this batch: typecheck:core, file-size, complexity, cognitive-complexity, changelog-integrity green; changed-area node:test 831/831 (0 failing) and vitest 480/482 — the two reds are autoCombo/provider-family-combos.test.ts timing out at 20s, which reproduces on the PURE release tip under the full vitest suite (and is already tracked by the Release-Green issue #13866), so it is inherited, not this batch's. Merged --admin per merge-gates §3/§4/§7.