[BUG] move_note's cross-project guard does not apply to is_directory=True, and rejects legitimate same-project moves

[foobl42]

Basic Memory 0.23.2.

The inconsistency

move_note's cross-project guard is skipped entirely for directory moves, so the
same destination is refused for a file and accepted for a directory.

_detect_cross_project_move_attempt is called at move_note.py:807, after the
if is_directory: branch has already returned at line 590. The separate
source_project vs active_project check above the branch still applies, so it is
specifically the leading-segment heuristic that directory moves never reach.

Reproduction

Projects foundry and work both exist. From a session scoped to foundry, with a
note in it:

Call	Result
move_note(id, destination_folder="work/scratch")	rejected, CROSS_PROJECT_MOVE_NOT_SUPPORTED
move_note(id, destination_folder="worknot/scratch")	succeeds
move_note("worknot/scratch", "work/moved", is_directory=True)	succeeds

Rows 1 and 3 disagree about the identical destination. Row 2 is a control: one letter
in the leading segment is the whole difference from row 1, confirming the trigger is
the project-name collision rather than anything structural about the path.

The false positive itself

Row 1 is a legitimate same-project move into an existing local folder. I understand
from #904 and #914 that this is Detection 1 behaving as designed, so this half is a
question about the tradeoff rather than a claim that something is broken.

#914 removed Detection 2 because "the structural heuristic is fundamentally ambiguous
— it cannot distinguish the cloud workspace routing shape from a legitimate
same-project nested folder", leaving MOVE_OUTCOME_MISMATCH as the backstop.
Detection 1 seems to have the same property: work/ is an ordinary folder name, and a
knowledge base organised by domain will have folders named after sibling projects as a
matter of course. In our case the destination folder already existed in the current
project, and the only workaround was git mv, which bypasses Basic Memory and leaves
the index to be reconciled separately.

Since #904 describes the post-move outcome check as the robust protection against the
#881 failure, it may be that the heuristic is now costing more in false positives than
it adds.

What would resolve it

• At minimum, make the two code paths agree — whatever the rule is, a file and a
  directory should not disagree about the same destination.
• If Detection 1 is kept, skipping it when the destination folder already exists in
  the current project would remove this class of false positive, since an existing
  local folder is good evidence of local intent.