Use WAL and durable connection defaults for SQLite

[AnnoyingTechnology]

Why

Davis currently leaves SQLite on its generic rollback-journal defaults. For a local, file-backed server database, WAL is the better application default: readers do not block a writer, a writer does not block readers, and writes are sequential. This matches the short multi-process requests produced by PHP and DAV clients.

The durability policy should remain explicit. This PR keeps synchronous=FULL rather than trading committed writes for speed and makes the existing 60-second lock wait explicit.

What changed

• configure file-backed SQLite connections with journal_mode=WAL
• retain synchronous=FULL
• set busy_timeout=60000 explicitly
• validate the applied journal mode and fail with an actionable error when the filesystem cannot support it
• allow SQLITE_JOURNAL_MODE=DELETE as the narrow fallback
• apply the middleware before Doctrine driver wrappers and leave MariaDB/PostgreSQL connections untouched
• test every applied SQLite pragma

Foreign-key enforcement and the missing SQLite constraints live in the database-invariants PR, keeping the two connection concerns independently reviewable and clean when merged together.

Operational notes

The README states the local-filesystem requirement, safe live-backup behavior, and the documented WAL-reset bug, including fixed releases and backports. There is deliberately no brittle runtime version-string gate because distributions may backport the fix without changing SQLite upstream version numbers.

Verification

• WAL and DELETE modes exercised against file-backed SQLite
• applied values verified as wal, synchronous=FULL, and a 60-second busy timeout
• invalid journal-mode configuration rejected
• MariaDB suite: 60 tests / 406 assertions with one expected SQLite-only skip
• combined with the first-class SQLite PR: 60 tests / 409 assertions

[tchapi]

Hi

What problem did you run into with DELETE, and what type of load did lead to that problems?

[AnnoyingTechnology]

Hi,

None.

It's a default config improvement. With concurrent PHP workers, WAL is SQLite’s appropriate default (unless the fs doesn't support it), and a logical default change along with #273

[tchapi]

unless the fs doesn't support it

Which is probably the case for most users self-hosting and running Davis on a NAS using NFS or SMB shares; so this default will not change.

[AnnoyingTechnology]

I don't see many cases where a user would access/expose their codebase+sqlite via NFS or SMB, especially when the data is light. But fair, I might be missing the actual userbase stack.

Most self hosting I've seen (in general) is with VPS, EC2 (ebs is exposed as local), LXC + ZFS or QEMU + ZFS (pve stack), all of which benefit from WAL.