fix(persistence): harden startup recovery

[SDSLeon]

Summary

Harden main-process persistence startup and legacy state repair without changing shared provider behavior or renderer UI.

• Keep the existing workspace migration ordering/drift repair on current master and retain regression coverage proving a schema-v28 database receives projects.workspace_id before project reads.
• Add schema version 30 to repair persisted thread configs whose legacy model is blank, and normalize the same legacy shape at every thread database IPC write boundary. Valid model configs pass through unchanged.
• Treat unavailable Linux secure storage (including Electron's insecure basic_text backend) as a degraded capability: use one random in-memory key for the process lifetime, never persist that key through an insecure backend, and never write plaintext secrets.
• Recover from an undecryptable or invalid stored safeStorage key with a fresh OS-encrypted key and a fixed, payload-free local warning. Expected recovery does not create a Sentry error. Unexpected backend inspection, encryption, file-read, and file-write failures still fail startup with sanitized messages.
• Stop swallowing SQLite failures during usage-event retention. Schema validation guarantees the table exists, so corruption, migration failure, CANTOPEN, EACCES, and other database faults remain real observable defects. Existing busy_timeout behavior still makes successful BUSY/LOCKED waits silent; exhausted lock failures propagate under the existing error policy.

Sentry issues and treatment

• Fixes LIGHTCODE-5Y — real startup defect. Current master already contains the version-29 workspace migration and additive drift repair; this PR keeps the prior-schema regression active while advancing the schema version.
• Fixes LIGHTCODE-53 — expected secure-storage capability limitation on affected Linux hosts, handled through a secure process-stable, session-only degraded mode with no Sentry exception. Unexpected storage inspection, encryption, read, and write failures remain observable errors.
• Fixes LIGHTCODE-19 — expected legacy persistence incompatibility, repaired at the versioned database and typed IPC persistence boundaries rather than suppressed in Sentry or special-cased by provider/UI code.

Validation

• pnpm exec vitest run src/main/db/migrations.test.ts src/main/db/projectsThreads.test.ts src/main/secretStorageKey.test.ts src/shared/ipc.test.ts — 4 files, 26 tests passed
• pnpm run typecheck — passed
• pnpm run lint — passed, including type-aware lint
• pnpm exec oxfmt --check on all 9 touched files — passed
• Commit hooks reran touched-file lint/format and the full typecheck — passed

Privacy and residual risk

Expected credential-storage degradation and key rotation emit only fixed local warnings and no telemetry. Thrown failures use fixed sanitized messages. This change never sends key bytes, secret values, backend exception text, commands, paths, prompts, repository data, auth values, or user content to telemetry.

When secure OS storage is unavailable, credentials encrypted with the process-stable in-memory key are intentionally not recoverable after restart. The app remains usable and no plaintext secret is stored, but users may need to authenticate again after enabling a supported system keyring. No renderer copy was added, so there is no localization surface in this PR.