Data history silently disables itself when the local database cannot be opened #2064

Describe the bug and steps to reproduce

If IndexedDB cannot be read on app boot, initDataHistory catches the error, returns captureEnabled: false and the app carries on. Data history then records nothing for the whole session, and the user is never told.

Seen in production on 2026-09-11: one user, five page loads in two and a half minutes across five different routes, every one failing with UnknownError: Internal error out of dataHistoryDb.getEntryCount(). Chrome raises that when its own IndexedDB backing store is unhappy, usually a corrupted database, so this is very likely a local condition on that machine rather than a bug in our code. It is also not reproducible on demand.

Expected behavior

Two gaps worth considering, neither urgent:

1. No signal. The user sees an empty history and cannot tell the difference between "nothing has been captured yet" and "history is broken for this browser profile". A note in the history UI when capture is disabled by an init failure would explain it.
2. No recovery. A corrupt local database stays corrupt across reloads, which is what the repeated failures look like. Deleting and recreating the Dexie database would fix that class of failure, though that also discards existing history, so it should be the user's choice rather than automatic.

What already works

The failure is contained. It is caught, reported to the error tracker with the operation name, and the user's actual data operations are unaffected. This is about the gap between that and the user knowing.

Browser and operating system:

Chrome 152, Windows 10. Release v10.18.0.

Filed from BetterStack error triage.