[RaviTharuma]

Summary

• Treat an absent lazily-created compression_run_telemetry table as empty during retention cleanup.
• Reuse the existing tableExists() DB helper, so a fresh install no longer emits a non-fatal SQLite warning 30 seconds after startup.
• Keep the existence probe inside the cleanup error boundary so a database lookup failure is reported without aborting later cleanup work.
• Preserve retention deletion unchanged once the first telemetry write or summary read creates the table.

Public-image reproduction:

diegosouzapw/omniroute:3.8.50
digest sha256:085c57adf499a8aaa9f35ccde95c0df9c11bd9ecd18d6c9edbf3b68b8079ba9d
[Cleanup] Error cleaning compression_run_telemetry: SqliteError: no such table: compression_run_telemetry
[Cleanup] Auto-cleanup complete: 0 deleted, 1 errors

The current release/v3.8.51 source has the same lazy-only table initialization and cleanup ordering. Its public Docker publish run did not produce a new image because the arm64 build exhausted memory: https://github.com/diegosouzapw/OmniRoute/actions/runs/33041245780

Related Issues

• Related to feat(backend): auto-cleanup/upsert for telemetry tables to bound storage.sqlite #6848
• Duplicate search found no open report for this fresh-install warning; no extra issue was created for this two-line fix.

Validation

• Change type: DB
• Focused tests and category gates from the golden path
• 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

Red-first proof:

# Before the production edit
✖ #6848 cleanupCompressionRunTelemetry: missing lazy table is an empty no-op
actual: { deleted: 0, errors: 1 }
expected: { deleted: 0, errors: 0 }

# After the guard
✔ #6848 cleanupCompressionRunTelemetry: missing lazy table is an empty no-op

# Review follow-up before moving the guard inside try
✖ #6848 cleanupCompressionRunTelemetry: contains table lookup failures
Error: injected table lookup failure

# After restoring the existing cleanup error boundary
✔ #6848 cleanupCompressionRunTelemetry: contains table lookup failures

Passed:

node --import tsx/esm --test \
  tests/unit/telemetry-auto-cleanup-6848.test.ts \
  tests/unit/repro-compression-run-telemetry-ms.test.ts \
  tests/unit/db/compressionRunTelemetry.test.ts
# 12 passed, 0 failed

npm run lint
npm run typecheck:core
npm run check:db-rules
npm run check:cycles

Tests Added Or Updated

• tests/unit/telemetry-auto-cleanup-6848.test.ts drops the lazy table and asserts cleanup returns an empty, error-free result.
• The same test injects a table-lookup failure and asserts cleanup contains it as { deleted: 0, errors: 1 }.
• Existing tests still prove old rows are deleted after the table exists.

Coverage Notes

The regressions execute the changed branches in cleanupCompressionRunTelemetry() against isolated, real SQLite. The injected failure goes through the real tableExists() call, and the existing sibling test covers the table-present deletion path.

Reviewer Notes

• No migration, schema, dependency, feature flag, or hot-path behavior change.
• The only writer and summary reader still lazily create the table in src/lib/db/compressionRunTelemetry.ts; the startup cleanup is the sole caller that can reach it first.
• The mandatory pre-commit formatter also normalized pre-existing unformatted regions in src/lib/db/cleanup.ts; those lines are mechanical only.
• ⚠️ base-red inherited: 🔴 Release branch not green: release/v3.8.51 #11449