feat: add SVN auto-watch graph synchronization

[lzl51230]

What problem does this solve?

Background auto_watch currently detects Git repositories only. In a pure SVN working copy, local edits and the file effects of svn update or svn commit do not trigger graph synchronization, so users must request a full regeneration to keep graph queries current.

Proposed solution

Extend the existing adaptive watcher with one Git-first SVN strategy for pure SVN working copies:

• Keep Git precedence when both .git and .svn metadata are present.
• Use a locally installed system svn client and machine-readable, local-only status output to observe per-entry revisions and working-copy states.
• Add content-sensitive fingerprints for status-selected source candidates so repeated edits remain detectable while a path stays modified or unversioned.
• Feed each distinct observation through the existing indexing callback, preserving current incremental-versus-full safety routing.
• Acknowledge an observation only after confirmed indexing success; CLI, parse, busy, and index failures remain retryable.
• Refresh the live MCP store after a successful background rebuild so the same server session sees the updated graph.
• Reuse the current adaptive watcher interval and auto_watch gate. Add no SVN-specific timer, VCS selector, status endpoint, indexing mode, or dependency.

The implementation would isolate SVN command/XML observation from watcher scheduling, add real svnadmin fixtures, and install SVN tooling only in CI jobs that run native C tests.

Design points for maintainer feedback

• The system SVN executable would be resolved to a trusted absolute path so a working-copy-local executable cannot shadow it.
• XML parsing would be a small schema-scoped streaming parser rather than a new XML dependency.
• Materialized local externals would participate without allowing a broken external to block primary working-copy synchronization.
• Pipeline discovery would remain authoritative for graph contents; conservative watcher triggers may produce a harmless pipeline no-op instead of duplicating private discovery rules.
• The watcher thread would publish a stale-store notification after success, while store close/reopen remains on the MCP event-loop thread.

Broader SVN parity, including history, authors, revision metadata in the graph, impact analysis, remote freshness checks, and bundled SVN binaries, is out of scope.

I am requesting design feedback before implementation because this feature touches watcher behavior, Makefile/test registration, and CI configuration.

Alternatives considered

• Root revision or svnversion only: misses mixed-revision and interior changes.
• Raw XML hashing: does not detect repeated content edits with unchanged status labels.
• Generic filesystem snapshots or dual SVN/filesystem watching: broader ownership and polling complexity than this focused feature.

Confirmations

• I searched existing issues and this is not a duplicate.