feat: add SQLite-backed durable job store

[seonghobae]

Why

The async web job model tracks jobs in an in-memory dict. Every restart wipes all job state, and the dict is invisible to any other process — so the app cannot scale past a single worker and users lose in-flight jobs on redeploy.

What

New stdlib-only module job_store.py: a SQLite-backed (WAL mode) JobStore that any async/worker layer can adopt so jobs survive restarts and are shared across processes.

• create / get / set_status / list_jobs / delete over a jobs table (id, status, created_at, updated_at, output_path, output_name, error, temp_dir)
• Status allowlist {queued, processing, done, failed}; invalid status raises ValueError
• Thread-safe (lock + short-lived connections) and multi-process-safe (SQLite file locking + WAL)
• Deterministic timestamps: callers inject now: datetime; the store never calls datetime.now()
• Clear edge semantics: duplicate create raises DuplicateJobError (a ValueError subclass), unknown get returns None, delete is idempotent, set_status preserves previously stored output/error fields when omitted

New files only; no existing files touched.

Tests

tests/test_job_store.py (15 tests, tmp SQLite file, injected timestamps, no network):

• create → get roundtrip; unknown get returns None; duplicate create raises
• set_status transitions update status + updated_at; error recording; omitted fields preserved; invalid status ValueError; unknown job KeyError
• list_jobs with and without status filter; delete + idempotent delete
• Durability: reopening a new JobStore on the same db_path still sees the job
• Concurrency: 8 threads racing set_status across 8 jobs, no torn writes

Gates

• python3.14 -m unittest discover -s tests: 128 tests, no new failures (baseline 5 macOS os.listxattr errors unchanged)
• python3.14 -m interrogate -c pyproject.toml job_store.py: 100%

🤖 Generated with Claude Code