fix(sync): stop bidirectional sync from clobbering local writes; add opt-in overwrite to move_page

[aniongithub]

Fixes the data-loss bug where update_page / delete_page reported success but the change vanished on the next sync tick, plus adds the long-requested opt-in overwrite to move_page.

The bug

In bidirectional sync the loop was:

fetch → merge → copyToWiki → reindex → copyFromWiki → commit → push
                ^^^^^^^^^ clobbered local edits

copyToWiki ran before copyFromWiki, so any wiki file the user had just written (via update_page, delete_page, etc.) was overwritten with the stale shadow-clone copy before we ever had a chance to commit and push it. The API call returned success, the change appeared to land, then ~30s later the sync tick silently undid it. Same mechanism for deletes — the deleted file was re-pulled from the clone.

This is consistent with the symptom in the host's mind-map.log where every reindex pass reported updated=N, unchanged=0 even with no real changes: every WriteFile was bumping mtimes and forcing a re-parse.

The fix

Commit-then-merge ordering. New flow:

copyFromWiki → add → commit (if any diff) → fetch → merge → copyToWiki → reindex → push

Local edits are part of HEAD before the merge runs, so git's 3-way merge does the right thing: local-only changes survive untouched, and genuine remote+local conflicts surface as conflict markers (and via Status.Conflicts) instead of being silently overwritten.

Two related cleanups in the same commit:

• copyFromWiki now mirrors deletions: clone-side files no longer present in the wiki are removed, so git add -A propagates the deletion.
• Both copyToWiki and copyFromWiki skip writes for byte-identical files, eliminating the reindex churn.

move_page opt-in overwrite

Engine: MovePage(ctx, from, to, MoveOptions{Overwrite: true}). Without that flag, returns the new typed sentinel ErrDestinationExists.

MCP tool: move_page gains an optional overwrite: true. On destination-exists it returns an error message that explicitly tells the agent to ask the user first, then retry — not a generic failure that invites a retry loop. SKILL.md and README updated with the same guidance.

When overwriting: destination's index entry is dropped before the rename so we don't leave stale rowid references; backlinks pointing at the destination are kept (they reflect [[dest]] text in other pages' markdown, which is unchanged).

Commits

Commit	Summary
3cc2800	fix(sync): commit local changes before merging remote — headline data-loss fix
019f87e	feat(wiki): opt-in overwrite for move_page
594b12a	test(sync): wiki API roundtrip through bidirectional sync

Test coverage

All three new sync tests fail on pre-fix main and pass on this branch.

• internal/sync: +3
  • TestLocalUpdateSurvivesBidirectionalSync — raw FS write survives a sync tick.
  • TestLocalDeleteSurvivesBidirectionalSync — raw FS delete propagates instead of being undone.
  • TestWikiUpdateAndDeleteThroughSync — same scenario but through wiki.UpdatePage / wiki.DeletePage with a real reindexer.
• internal/wiki: existing tests retained, +1 (TestMovePageOverwriteReplacesDestination), and TestMovePageFailsWhenDestinationExists strengthened to assert the typed error via errors.Is.
• internal/mcp: +2
  • TestMovePageDestinationExistsIsRecoverable — verifies the agent gets an actionable message naming overwrite=true.
  • TestMovePageOverwriteSucceeds — exercises the reject-then-retry-with-confirmation flow.

Verification

Run inside the project's devcontainer:

• go test ./... — green
• go test -race ./... — race-clean
• go vet ./... — clean
• go build -o /tmp/mind-map ./cmd/mind-map + npm run build (webui) — both succeed