The recorded folder list is a union over the model roots keyed by relative
path, but remove_known_folder() dropped an entry unconditionally. Deleting
<rootA>/test in the sidebar therefore hid a "test" that <rootB> still held:
the node disappeared from the next tree load and came back after the next
scan, which reads as "the delete did not work". The same call purged cache
entries by relative folder, so removing an empty <rootA>/test2 also evicted
the model cards of <rootB>/test2 until the next scan, and
rename_known_folder() re-keyed both the recorded folder and the "folder"
field of models that never moved.
* _folders_present_on_disk() answers "which of these relative folders does
some root still hold?" with stats off the event loop (model roots can live
on slow network shares) and reports nothing for stand-in scanners without
roots, which preserves their previous behaviour.
* remove_known_folder(folder, absolute_path=None) keeps the entries another
root still owns and purges by the removed directory's absolute path when
the caller knows it. Without a path the relative-folder filter stays as the
documented fallback: it prunes the entry (disk-verified either way) but
cannot tell same-named copies apart.
* rename_known_folder() re-adds the survivors of the old name and only
touches cache entries whose file_path sits inside the renamed directory.
Tests: the two delete tests now remove the directory from disk first, which
is what the contract always assumed, plus three new scanner tests (a twin
keeps the entry, the entry goes once no root holds it, the twin's cards
survive the purge), one for the legacy fallback and one for a rename that
leaves a twin behind.
Will Miao
5ebf5aeccc