watcher treats zero-result sync as success and clears pending files

[thismilktea]

Problem

FileWatcher.flush() currently treats any resolved syncFn() result as a successful sync.

However, CodeGraph.sync() can return an all-zero result when it fails to acquire the cross-process file lock, instead
of throwing. In that case, the watcher still clears pendingFiles and considers the edit handled.

This can incorrectly mark locally edited files as fresh even though they were never indexed.

Impact

A possible sequence:

1. watcher sees a file change and adds it to pendingFiles
2. syncFn() runs
3. another process holds the CodeGraph file lock
4. CodeGraph.sync() returns a zero-result no-op instead of throwing
5. FileWatcher.flush() treats it as success and clears the pending entry
6. the graph remains stale until some later file event happens

Expected behavior

If there are pending files and syncFn() resolves with:

• filesChanged === 0
• durationMs === 0

then the watcher should treat that sync as no progress, not success:

• keep pendingFiles
• do not call onSyncComplete
• let the existing retry path reschedule sync

Suggested fix

A minimal fix is in src/sync/watcher.ts only:

• detect pendingFiles.size > 0 + zero-result sync
• treat it as unfinished
• preserve pendingFiles
• rely on the existing retry scheduling in finally

Notes

The shared MCP daemon in v0.9.5 reduces one common source of lock contention, but does not fully eliminate this bug
because other writers can still contend for the lock.

[colbymchenry]

Fixed in #450 by @thismilktea (with a small refactor on top from me — same observable behavior, but routes the lock-failure detection through a typed LockUnavailableError thrown by CodeGraph.watch()'s sync wrapper, so the watcher's catch path handles it precisely instead of pattern-matching on (filesChanged === 0 && durationMs === 0)).

A/B-validated end-to-end on macOS against a real index: with another writer holding .codegraph/codegraph.lock, the watcher now preserves pendingFiles (so the per-file staleness banner from #403/#428 stays accurate) and reschedules through the existing retry path. When the lock releases, the next sync drains pending files normally.

Quiet on the noisy side too — lock-failure goes to logDebug only (no onSyncError callback), so a long-running external codegraph index doesn't spam stderr every debounce cycle through the MCP daemon's auto-sync error handler.