Autosave must yield to the user: make the shared mutation guard ownership-aware

[dovvnloading]

The last remaining confirmed finding from the R6.6/R6.7/R6.8 audit — deliberately deferred out of #137 rather than bolted onto it.

The bug

chat_library.py's _mutation_in_progress flag serializes loadChat/saveChat/newChat by dropping a blocked intent and warning "Another chat operation is already in progress."

That contract is honest when only user-initiated intents can hold the flag — the user really did start two things. R6.6 then had a background autosave task claim the same flag, and the asymmetry went unnoticed: a tick that happened to be mid-write made the user's own Save/Load/New Chat vanish, with a warning naming an operation they never started.

A background convenience feature must never beat the user to their own data.

The fix

The guard now records who holds it, and the two directions differ:

arriving	holder	behavior
user	autosave	wait the tick out, then proceed (new)
user	another user	drop + warn, exactly as before
autosave	anyone	skip this interval, exactly as before

The wait is bounded — AUTOSAVE_YIELD_TIMEOUT_SECONDS = 2.0, roughly 40× the measured 10–50ms tick. A tick genuinely stuck on sqlite's own 30s lock timeout degrades to the pre-fix drop rather than freezing the UI, but with a message that names autosave instead of "another chat operation" — which is what made the original warning read as a bug. Every outcome is at least as good as before; the common one is strictly better, in that the Save just works.

The guard's shape now lives in one factory, _new_mutation_guard(), so chat_library, autosave and the tests can't drift apart on it. Its release Event is constructed with no running loop on purpose — safe since 3.10, and register_chat_library really is called outside a loop, which is the exact hazard that broke R6.6's own create_task call.

Mutation testing caught two bad tests before this shipped

The first attempt failed its own bar, twice:

1. The test used a hand-written double that reimplemented the claim/release itself. Mutating the real _guarded_tick — dropping its owner tag, or its release signal — left the test green. The production wiring was never under test at all. Rewritten to drive the real register_autosave loop with a deliberately slow save, bounded by asyncio.wait_for so a lost wakeup fails rather than merely running slow.

2. That exposed a second gap: the rewritten test only ever observed the first tick to claim the guard, so removing _guarded_tick's released.clear() still survived. But without it, every tick after the first wakes a waiter on a stale signal, which re-checks, finds the guard still held, and drops the user's intent exactly as before. A fix that works once and then quietly stops working is worse than no fix — so there's now a test pinning the steady state, not just the first run.

All 5 mutants killed, including both that initially survived.

Verification

2375 pytest (+5), 1053 vitest unchanged (no frontend touched), tsc/eslint/build clean, Qt burn-down gate unchanged at 152.

Also re-driven against a scratch copy of a real ~/.graphlink/chats.db: 5 real legacy chats still load and tick without a spurious rewrite through the rewritten guard. Real chats.db verified untouched.

With this, every confirmed finding from the audit is closed except one documented as knowingly unfixable safely: the crash sentinel reporting a phantom crash when a second instance is live, which needs a pid-liveness check with no safe portable form (os.kill signal-0 is POSIX-only; on Windows it would terminate the other process).