fix(watcher): recover after prolonged lock contention

[stsoul]

Summary

• keep the file watcher retrying when another CodeGraph writer holds the project lock
• cap exponential lock backoff at the existing maximum interval instead of permanently degrading auto-sync
• add a regression test that crosses the former five-retry boundary and succeeds on the ninth attempt
• keep terminal degradation unchanged for watch-resource exhaustion and persistent non-lock sync failures

Root cause

The bounded retry behavior added around #891 prevents a hot retry loop, but it also turns recoverable lock contention into a one-way failure. If a competing indexer holds the lock longer than five watcher retries, degrade() stops the watcher and clears pending state. Releasing the lock later cannot recover the running MCP session.

This change bounds the retry rate rather than the retry lifetime. The lock retry counter saturates at the fifth backoff step, so retries continue at the existing 30-second ceiling. A successful sync still resets the counter immediately.

Impact

Long-running index or sync processes can finish without permanently disabling auto-sync in another CodeGraph process. Pending files remain visible as stale while the lock is held and are cleared after the next successful sync.

Validation

• added a Vitest regression covering eight consecutive LockUnavailableError results followed by a successful ninth attempt
• downstream npm run cg:smoke passed against the same watcher change, including recovery after the former retry boundary
• verified the branch differs from main by exactly the three intended files

The upstream test suite was not run from a separate checkout; this draft relies on the included focused test and downstream contract until CI runs.