fix: serialize persistent embedding cache writes

[dajiaohuang]

Outcome

Serialize persistent embedding-cache writes that target the same SQLite path within one process.

The shared path lock now protects both database initialization and the complete INSERT / prune / commit transaction. Reads remain concurrent under WAL, while locks held by another process still use the configured SQLite busy timeout and retain the existing fail-open behavior.

Root cause

The cache already shared an initialization lock across embedder instances, but each put_many() transaction ran outside it. Sixteen same-process writers could therefore consume the 25 ms SQLite busy timeout while contending with another cache write or a sibling instance's initialization. That is why both first attempts of the PR #7 push and pull-request workflows failed at the same concurrency assertion, then passed unchanged on rerun.

Retrying SQLite operations would blur the intentional external-lock latency bound. Serializing only writes owned by this process removes avoidable contention without changing cross-process fallback semantics.

Regression coverage

The existing 16-embedder regression now:

• synchronizes every writer at a barrier;
• holds the first SQLite write transaction for 100 ms, longer than the configured 25 ms busy timeout;
• verifies all 16 cache writes complete without fail-open errors; and
• continues to verify that all 16 rows are persisted.

The separate externally locked-cache test still verifies a write fails open in under 500 ms.

Validation

• pytest tests/test_embeddings.py::test_parallel_embedders_share_cache_path_lock tests/test_embeddings.py::test_locked_cache_write_fails_open_quickly
• 20 consecutive runs of test_parallel_embedders_share_cache_path_lock
• pytest — 308 passed, 14 skipped
• ruff check .
• git diff --check

Boundary review

• No package, schema, model identity, or public API changes.
• No retry loop or busy-timeout increase.
• No new dependency or service.