fix: Prevent concurrent write corruption in savings.jsonl

[Pringled]

Multiple MCP server processes appending to savings.jsonl simultaneously caused a small amount of lines to contain interleaved JSON. Added a lock for unix, Windows can technically still write malformed lines but it won't break the CLI, just show a warning (if we want to do it for windows we need to add a dependency which I don't really want to do for this).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Files with missing lines	Coverage Δ
src/semble/stats.py	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[greptile-apps]

Confidence Score: 4/5

The change is safe to merge; it adds write serialisation for a non-critical stats file and degrades gracefully to an unlocked write on Windows.

The core locking logic is correct and the lock is properly released via file-close. The two issues — an intra-function import and flock OSErrors being absorbed by the outer handler — are quality improvements rather than correctness blockers for a low-stakes stats file.

src/semble/stats.py — the flock error-handling path and module-level import placement are worth a second look.

Comments Outside Diff (1)

1. src/semble/stats.py, line 1-6 (link)

   import fcntl is placed inside the with block, re-running on every call to save_search_stats. Python's import system caches it, so it isn't expensive, but the idiomatic pattern is a module-level conditional import so the availability check happens once at startup and the rest of the function stays clean.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

_{Reviews (1): Last reviewed commit: "Add no cover" | Re-trigger Greptile}

[stephantul]

Some comments, not sure how easy it is.

[stephantul]

One issue I can see here is that this import is always attempted (and always fails) on Windows and systems that do not support it.

Maybe move it somewhere else or cache the result of the import operation? I honestly don't know how long a failed import takes, but this is tried on every save.

[stephantul]

Is there some way to distinguish between these failure cases? I.e., just not being supported or a lock contention? The former should not be retried.