fix(db): periodically truncate the SQLite WAL on long-running servers

[maxmad64bis]

⚠️ base-red inherited: #9985

Summary

• SQLite's auto-checkpoint moves WAL pages back into the main database file but never shrinks the
  WAL file itself. Only wal_checkpoint(TRUNCATE) reclaims it, and its single caller is
  closeDbInstance() — a long-running server never closes its DB, so the WAL grows until the next
  restart. Observed locally: a 154 MB WAL against a 143 MB database after 24h of uptime.
• Adds a periodic wal_checkpoint(TRUNCATE) mirroring the existing DB health-check scheduler: same
  self-gating (cloud, build phase, automated test process), same unref()ed interval, same env-var
  override convention. Default 6h; OMNIROUTE_WAL_TRUNCATE_INTERVAL_MS overrides it, 0 disables.

Related Issues

• None filed upstream.

Validation

• Change type: DB
• Focused tests and category gates from the golden path:
  tests/unit/db-wal-truncate-scheduler.test.ts (6/6), npm run test:vitest (368/368),
  npm run check:env-doc-sync
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR
• SonarQube is temporarily opt-in while the private project has no quota; it is not a PR gate.

Tests Added Or Updated

• tests/unit/db-wal-truncate-scheduler.test.ts (new)

The scheduler gates itself off under isAutomatedTestProcess(), like the health-check scheduler it
is modeled on, so the test reads the wiring rather than running it — same approach and helper as
tests/unit/lib/jobRegistry/boot-wiring.test.ts.

Coverage Notes

• The new code lives in src/lib/db/core.ts and cannot execute under the test runner by design:
  the same gate that keeps the existing health-check scheduler from starting in tests applies to
  it. The test therefore pins the wiring, the env-var contract and the shutdown/re-open cleanup at
  source level. The behavior itself is one checkpointDb(db, "TRUNCATE") call, already exercised
  where closeDbInstance() uses it.

Reviewer Notes

• TRUNCATE waits for readers and can no-op under concurrent write load. That is expected and
  non-fatal; it retries on the next tick.
• The timer is cleared in closeDbInstance() before the shutdown checkpoint, and again on re-open,
  so no timer leaks between DB instances.
• OMNIROUTE_WAL_TRUNCATE_INTERVAL_MS is documented in .env.example and
  docs/reference/ENVIRONMENT.md; a non-numeric or negative value falls back to the default.