fix(db): retry transient SQLite writer locks

[abrichr]

What changed

Capture now retries an insert when another SQLite writer holds the per-capture database lock for a short time. It rolls back the failed transaction before each retry and stops after two retries. If the lock remains, the writer still exits with an error and Recorder reports that failure.

The SQLite connection's existing five-second lock wait is now explicit. The total database wait is bounded at about 15.25 seconds.

Why

A Windows live-recorder run failed when the memory-stat process hit a database lock while other capture writers were committing. This change lets a short conflict clear. It doesn't accept a partial database or hide a writer failure.

Test evidence

• A real-file test holds the SQLite lock, releases it during the first retry, and confirms one row is committed.
• A second test keeps the lock and confirms the final write error still reaches the caller.
• The Python 3.10 fallback covers the database, table, and schema lock messages.
• The focused retry and writer suite passes: 12 tests.
• The full local suite passes: 605 tests, with 13 expected skips.
• Ruff and the diff check pass.