fix(db): degrade getSettings() to defaults instead of crashing Home on corrupted SQLite (#14060)

[diegosouzapw]

Closes #14060

Root cause

src/app/(dashboard)/home/page.tsx awaits getSettings() (src/lib/db/settings.ts) with no try/catch during server-side rendering. When the SQLite pager reports corruption (SQLITE_CORRUPT / "database disk image is malformed") localized to the key_value table, that unguarded read throws synchronously and crashes the Home Server Component render, producing the generic Next.js "Internal Server Error" the reporter saw — while every other DB-backed startup consumer (optimizationSettings.ts, proxyLogger.ts, memory/index.ts, etc.) already catches the identical error and falls back to defaults.

Fix

• src/lib/db/settings.ts: wrapped the key_value read in getSettings() in try/catch; on error, console.warn (mirroring optimizationSettings.ts's pattern) and fall through to the existing in-memory defaults object instead of throwing.
• src/app/(dashboard)/home/page.tsx: defense-in-depth — wraps getSettings() in .catch() so a future unguarded read anywhere in its dependency chain can't regress this same crash.

Regression test

tests/unit/settings-14060-getsettings-corrupt-db.test.ts — corrupts only the on-disk page backing the key_value table (located via sqlite_master.rootpage) on an otherwise-valid, migrated storage.sqlite, reopens the DB (boot probe / other tables stay readable), then calls getSettings().

RED (on unfixed base, per the plan-file's own proof — verbatim log match to the reporter's):

[DB] Failed to read database optimization settings; using defaults: database disk image is malformed
✔ getSettings() throws (does not degrade) ...

GREEN (with the fix, inverted assertion per the analysis audit note):

[DB] Failed to read settings; using defaults: database disk image is malformed
✔ getSettings() degrades to defaults (does not throw) when only the key_value table's page is corrupted (9253ms)
ℹ tests 1 / pass 1 / fail 0

Gates run

• node --import tsx/esm --test tests/unit/settings-14060-getsettings-corrupt-db.test.ts → pass 1/1
• npm run typecheck:core → exit 0
• node scripts/check/check-dashboard-typecheck.mjs → OK, 206 pre-existing errors within frozen baseline
• npx eslint --suppressions-location config/quality/eslint-suppressions.json <changed files> → clean
• node scripts/check/check-file-size.mjs → no violations on touched files
• node scripts/check/check-complexity.mjs → OK (2904 violations, baseline 3218)
• node scripts/check/check-cognitive-complexity.mjs → OK (1316 violations, baseline 1437)
• node scripts/check/check-changelog-integrity.mjs → OK
• Full existing settings-area suite: tests/unit/{db-settings-crud,db-settings-split,db-settings-extended,settings-api,settings-debugmode-default,db-settings-debug-mode-default-10312,database-settings-maintenance}.test.ts → 108/108 pass

Existing tests aligned

None — no pre-existing test encoded the old (crashing) behavior; only the new plan-file repro did, and its assertion was inverted per the analysis audit note before use.

Plan-file: _tasks/pipeline/bugs/2-implementing/14060-bug-dashboard-internal-server-error-with-malformed-sqlite-data.plan.md

Rework (merge-batch 2026-09-23)

Defect found in review: the try/catch added inside getSettings() replaced its fail-closed behavior with defaults. isAuthRequired() (src/shared/utils/apiAuth.ts) relies on getSettings() throwing so it lands in its catch and requires auth (the safe default, also on SQLITE_BUSY). With the swallow, a read error returned password-less defaults, which disabled auth for loopback requests and opened the first-password bootstrap write (POST /api/settings/require-login).

Correction:

• src/lib/db/settings.ts: reverted to the base version, so getSettings() rejects on a read error again. It is no longer in this PR's diff.
• New src/app/(dashboard)/home/loadHomeSettings.ts: a display-only helper that catches the error, logs a warning and returns { setupComplete: false }. home/page.tsx uses it, so Home still degrades instead of returning 500, and no auth/authz path sees defaults.
• tests/unit/settings-14060-getsettings-corrupt-db.test.ts rewritten. It corrupts only key_value's root page and asserts:
  • (a) isAuthRequired(loopbackRequest, { loopback: true }) stays true on a protected path and on the bootstrap write;
  • getSettings() still rejects;
  • (b) loadHomeSettings() resolves to defaults without throwing, plus a healthy-settings pass-through case.

Red → green:

• On the previous PR head's settings.ts (7064cca), the test fails with AssertionError: isAuthRequired() must fail closed when settings are unreadable — actual: false, expected: true.
• With the correction it passes 2/2.

Gates (after merging origin/release/v3.8.51):

• Focused tests pass 42/42 (settings-14060 + api-auth).
• typecheck:core has only the inherited cliproxyAccountHealth.ts(157,5) TS2322.
• eslint on changed files: clean.
• check-file-size: OK.
• check:open-sse-typecheck is red with open-sse/executors/auggie.ts TS2769/TS18047. That error is inherited from the release tip (fix(auggie): resolve spawn EINVAL when running the CLI shim on Windowsfix(auggie): resolve spawn EINVAL when running the CLI shim on Windows #14215); this PR changes nothing under open-sse/.
• check-dashboard-typecheck is red with src/lib/combos/intelligentRouting.ts TS2698. That error is also inherited from the release tip (last touched by fix(routing): honor manual auto weights and weight weekly reset urgency higher #14176); this PR does not touch the file.