[BUG] Case-only renames on macOS (case-insensitive APFS) fail via move_note and create duplicate index entries

[mahush]

Note: This issue was written with AI assistance, based on a real usage session.

Bug Description

On macOS with the default case-insensitive APFS volume, renaming notes or folders so that only the letter case changes misbehaves when done through the MCP tools. Several distinct problems: a case-only file rename is rejected, a case-only folder rename silently doesn't change the folder's case on disk, directory moves leave empty orphan directories behind, and case-only renames leave duplicate entries in the index that a normal sync won't clear.

Steps To Reproduce

1. Install version 0.22.1, vault on default case-insensitive APFS.
2. File rename: call move_note to rename config.md → Config.md (same folder, only case differs).
3. Folder rename: call move_note (directory) to rename a folder reviews → Reviews.
4. Let the server sync / restart it, then list_directory; also inspect the folder on disk.

Expected Behavior

• A case-only rename succeeds via move_note (a plain mv config.md Config.md / Finder does it fine).
• A case-only folder rename actually changes the folder's case on disk.
• Directory moves remove the emptied source directory.
• No duplicate/phantom index entries result.

Actual Behavior

1. move_note refuses the case-only file rename with Move Failed - Destination Already Exists — its destination-exists check treats the case-insensitive-equal path as an existing file. Requires a two-step rename via a temporary name to work around.
2. The case-only folder rename reports success but doesn't change the folder's case on disk — the files end up back in the pre-existing lowercase directory; only the index briefly reflects the new case. (A mv on the folder does work.)
3. Directory moves leave the emptied source directory behind on disk. After a directory move, the original (now empty) folder remains — e.g. an empty debuggng/ is left after its contents move to Debugging/ — so renames accumulate orphan empty folders.
4. Duplicate index entries: after renaming, every affected note appears twice in list_directory — once under the new-cased path, once under the old-cased path — and an incremental sync / server restart does not remove the stale ones (they even get re-dated). Running bm reindex --full rebuilds from the filesystem and clears them.

Environment

• OS: macOS 26.6.1 (default case-insensitive APFS)
• Python version: 3.14.7
• Basic Memory version: 0.22.1
• Installation method: Homebrew
• Client: MCP (streamable-http transport)

Additional Context

• mv/Finder perform these case-only renames fine, so this is about the tool/index behavior, not a filesystem limitation.
• Workaround that fully recovers a duplicated index: bm reindex --full -p <project> (incremental sync alone does not). Orphan empty directories must be removed manually (e.g. rmdir).
• Possibly related: file_path lookups are byte-wise, so NFC/NFD filename variants create duplicate entities (macOS + Syncthing) #1275 (NFC/NFD filename variants duplicating entities on macOS) — may share a cause, though that's Unicode form rather than letter case.

Possible Solution

Treat a case-insensitive same-path destination as the same file in move_note (allow the rename), remove the emptied source directory on a directory move, and make sync reconcile case-only path changes so duplicates aren't created / are pruned — rather than relying on a full reindex.