fix(db): treat an unreadable image as proof of corruption

[dandwhelan]

Fixes the pre-existing db_manager test failure on main (the "corruption" subtest), by fixing the code rather than the test.

What was wrong

6e41ad7 (#35) narrowed quarantine to a positive corruption verdict after two incidents destroyed databases that were never damaged. That narrowing is right for contention, but it went one branch too far: when quick_check could not run at all, the database was kept whatever the reason.

That inverted the policy. Quarantine could only fire for a file that opens fine and grades bad — the milder damage — while a file whose header SQLite cannot even recognise (file is not a database) was kept for ever.

Two places in the codebase already documented the behaviour that had been lost:

• _cleanup_db_retry's own docstring: quarantine exists because "looping on a permanently corrupt file would just restart Predbat for ever" — which is precisely the file that was being kept.
• DatabaseManager.recover_from_error calls _cleanup_db_retry so that it "recovers or starts a fresh database rather than looping". It could no longer do either, leaving Predbat running with db_primary set and every history write failing for the life of the process, unnotified.

Both incidents behind 6e41ad7 were contention — a lock, and a file a later integrity_check proved healthy. Contention is already excluded one branch earlier by the OperationalError check, and every benign SQLite failure (BUSY, LOCKED, CANTOPEN, IOERR) is an OperationalError. What still reaches quick_check as a plain DatabaseError carrying a result code is SQLITE_CORRUPT or SQLITE_NOTADB — both positive reports of damage.

The change

Quarantine now also fires when quick_check itself fails with one of those two codes.

The match is on the result code, not the exception class: ProgrammingError ("Cannot operate on a closed database") is a DatabaseError too, and a bug of our own must never cost the user their history. The code is masked to its low byte so extended codes such as SQLITE_CORRUPT_INDEX (779) still match.

Everything 6e41ad7 protects is untouched — contention, a clean verdict, and an error with no corruption code all still keep the database.

Tests

The test asserted the old behaviour and had been failing on main since 6e41ad7, which never updated it. It now pins every branch:

Scenario	Expected
Transient malformed error, then success	kept
Repeated OperationalError (lock contention)	kept
quick_check grades ok, cleanup still failing	kept
DatabaseError with no corruption code (ProgrammingError)	kept
quick_check grades the image damaged	quarantined
Quarantine moves -journal/-wal/-shm with the database	sidecars follow
quick_check cannot run: file is not a database	quarantined

The positive-verdict case the old test claimed to cover was in fact exercising the unreadable path — it is now tested for real, against a genuinely damaged database image (garbage written over pages 3-6, header left intact) rather than mocks.

Verified: db_manager 9/9 pass, and the new test fails against the pre-change db_engine.py on the unreadable case, so it genuinely pins the semantics. black clean and ruff --select=F401 (as CI runs it) clean.

🤖 Generated with Claude Code