Watcher loses its successful baseline across unwatch/watch #2743

Version

codebase-memory-mcp -v0.12.1

Platform

Linux (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

Description

In v0.12.1, a project watch can be removed when its final daemon session
subscriber disconnects while the daemon itself remains alive. Re-registering
the same project creates a fresh watcher state. Its initial poll adopts the
current Git HEAD as the baseline and starts with an empty dirty-state
signature, without checking whether that graph generation was successfully
indexed before the disconnect.

This can cause two observable failures:

• If the previously indexed worktree was dirty and remains unchanged, the
  reconnect can trigger a redundant full reindex.
• If a commit is made while the project is unwatched and the worktree is clean
  when it reconnects, the fresh baseline can absorb the new HEAD; the
  watcher then sees no change and may leave the graph stale.

The issue is limited to a daemon that stays running while the final watch is
removed and later recreated. A daemon restart already loses all in-memory
watcher state.

Reproduction

Reproduction

1. Start the daemon and watch a Git project.
2. Make a worktree change and let the watcher index it successfully.
3. Disconnect the final session that owns this project's watch, without
   restarting the daemon.
4. While the project is unwatched, commit a change and leave the worktree
   clean.
5. Reconnect the session so the project is watched again.

The watcher initializes from the new HEAD and does not schedule an index for
the commit made while disconnected. An unchanged dirty worktree can also
reproduce the redundant-index case by reconnecting without step 4.

Expected behavior

The daemon should retain the last successfully indexed Git HEAD and dirty
signature across a watch removal/re-registration for the same project and
root. It should detect changes that happened while the project was unwatched.
The saved baseline should only be reused while the project's graph database
generation is unchanged; a replaced or missing database should force an
index. Failed and busy-skipped index attempts must not advance the saved
baseline.

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.