Make SQLite durability configurable #24

Context

LiteQueue forces these settings on the write connection:

PRAGMA journal_mode = WAL;
PRAGMA temp_store = MEMORY;
PRAGMA synchronous = NORMAL;

The recent commits correctly stopped overriding SQLite's cache size. The durability part of the backlog remains open: callers cannot request synchronous=FULL through the LiteQueue API.

In WAL mode, NORMAL protects database consistency but can lose recently committed transactions after an operating-system crash or power loss. This may be the right performance tradeoff for many queues, but persistent task queues also have use cases where the latest commit must survive power loss.

Why implement this

Durability is part of the queue's data-loss contract. The library should make the tradeoff explicit instead of choosing it silently. A small policy is easier to support safely than accepting arbitrary PRAGMA text.

Proposed direction

• Add a narrow constructor option such as durability="normal" | "full".
• Validate it before opening or mutating the database.
• Apply the matching synchronous setting to the write connection.
• Keep normal as the default if preserving current performance is important.
• Document application-crash, OS-crash, and power-loss behavior for each mode.
• Query and test the effective PRAGMA value.

Acceptance criteria

• Users can select full WAL durability.
• The default remains explicit and documented.
• Invalid durability values fail before schema changes.
• Tests verify the effective journal_mode and synchronous values.
• Documentation explains the performance and durability tradeoff.
• make test passes.