fix(db): report checkpoint failure instead of a false "completed" on WAL TRUNCATE busy

[hartmark]

What Problem This Solves

The 11 GB live database's WAL file had grown to 11.7 GB -- nearly as
large as the database it shadows -- and stayed that way across restarts
despite an existing periodic wal_checkpoint(TRUNCATE) scheduler
(startWalTruncateScheduler, every 6h) whose own logs claimed success the
entire time. On the next restart, an unrelated startup VACUUM over the
now-huge database blocked all HTTP traffic for ~15-20 minutes (better-sqlite3's
VACUUM is synchronous and blocks Node's single thread).

Root Cause

checkpointDb() called the wal_checkpoint(mode) pragma and unconditionally
returned true, ignoring the {busy, log, checkpointed} row SQLite always
returns
(docs). busy != 0
means SQLite could not get the lock this mode needs -- for TRUNCATE, full
exclusivity: any other open connection, reader or not, blocks it -- and the
WAL file was not shrunk, no matter how many frames checkpointed reports.

Both callers therefore always logged success:

• The periodic scheduler printed "[DB] Periodic SQLite WAL checkpoint completed (TRUNCATE)." every tick, even when the checkpoint silently
  no-oped.
• closeDbInstance() did the same on shutdown.

On a server that is rarely fully idle (this one runs continuous
SSE/embedding/batch traffic on a single long-lived connection), TRUNCATE
may never actually get the exclusive lock it needs within a given tick, so
the WAL just grows monotonically -- with the logs claiming success the whole
time, so nobody could tell from the logs alone that anything was wrong.

I verified this empirically before writing the fix: opening a second
connection with an uncommitted read transaction on a real WAL-mode SQLite
file reliably reproduces busy: 1 and a non-truncated WAL file; committing
that transaction (even without closing the connection) reliably reproduces
busy: 0 and truncation to zero bytes.

Fix

checkpointDb() now reads the pragma's own busy field and only reports
success when busy === 0. Both call sites now log the deferred/no-op case
too (previously silent), so a WAL that never finds an idle moment is visible
in the logs instead of looking identical to a healthy server.

This does not change the checkpoint cadence or add any new configuration --
it fixes the return value so the existing logging is truthful.

Evidence

New regression test opens a real WAL-mode SQLite file, holds it busy from a
second connection with an open read transaction (reproducing the exact
"server never fully idle" condition that hid this bug in production), and
asserts checkpointDb() correctly reports false while busy and true
once the lock becomes available.

$ node --test tests/unit/db-wal-checkpoint-busy-detection.test.ts
✔ checkpointDb reports failure (not success) when TRUNCATE cannot get the lock it needs
✔ checkpointDb reports success once TRUNCATE actually gets exclusivity
tests 2, pass 2, fail 0

$ node --test tests/unit/db-wal-truncate-scheduler.test.ts   # pre-existing, unmodified
tests 6, pass 6, fail 0

$ node --test tests/unit/db-core-extended.test.ts tests/unit/db-core-init.test.ts \
    tests/unit/db-reset-module-state.test.ts tests/unit/graceful-shutdown-sighup-8045.test.ts
tests 44, pass 44, fail 0

• eslint on both touched files: clean (3 pre-existing, unrelated unused-var
  errors in core.ts confirmed present on unmodified release/v3.8.51 too --
  not touched by this PR)
• tsc --noEmit: no errors in touched files

[hartmark]

Superseded by #12853 (merged 2026-09-08T12:29:42Z), which fixes the exact same root cause -- wal_checkpoint()'s busy field being ignored so TRUNCATE always logged "completed" even when it silently no-oped -- with a more complete implementation: it extracts the scheduler into its own walMaintenance.ts, adds a structured WalCheckpointOutcome, tracks a busy streak, and schedules a PASSIVE retry on busy instead of just waiting for the next full-interval tick. It also covers closeDbInstance()'s own checkpoint call the same way this PR did.

Verified #12853's walMaintenance.ts on current release/v3.8.51: runCheckpointNow() parses {busy, log, checkpointed} from the pragma result and only reports ok when busy !== 1, matching this PR's core fix, then goes further with the retry/streak logic. Closing this one in favor of the already-landed, more thorough fix.

Thanks @maxmad64bis for landing #12853.