storage(doctor): diagnose without changing persisted journal mode

[TusanHomichi]

Problem

At f369981, doctor::run uses storage::open_existing, which passes through
the normal writable connect_options with journal_mode(Wal). Opening an
existing DELETE-mode database for diagnosis changes its persisted journal
mode before verify_invariants checks it. This violates ADR 0003 and the
documented read-only diagnostic contract.

Reproduction observed on 2026-09-05

Create a temporary data directory with backups/, exports/, and instance/.
Using Python's sqlite3 module, create consolebook.db with one invented table
and confirm PRAGMA journal_mode returns delete. Hash the file, then run:

target/debug/consolebook-server --data-dir <scratch-directory> doctor

Observed: doctor exits 1 because the toy database lacks application tables,
but reports ok pragma journal_mode wal. A new sqlite3 connection reports
wal and the database SHA-256 differs. No production or preview data was used.
The same options path is used regardless of whether application tables exist.

Acceptance criteria

• Give diagnostics an explicitly read-only connection path that observes
  persisted journal state instead of setting it to the expected value.
• Preserve the shared invariant-reporting logic without changing writable
  startup/backup behavior through a global options workaround.
• Prove missing databases are not created, misconfigured databases remain
  byte-identical, and healthy WAL installations can be diagnosed while live
  and stopped. Include read-only-filesystem/WAL-sidecar behavior in the design.
• Document which PRAGMAs describe connection-local settings versus persisted
  state, and report observed mismatches honestly.

This is a separate diagnostic/storage contract repair found during the
repository orientation audit (#53).