fix(macOS): keep the GUI responsive when many files are added to a sync folder

[ftapps]

Problem

On macOS the client's window freezes for as long as it takes to process a large
batch of files, in two situations users hit routinely:

• many files are added at once to a watched sync folder;
• a new account is set up against a server that already holds a large tree.

The sync itself is fine — it is the GUI that stops responding until the initial
processing is over.

Cause

FolderWatcherPrivate::startWatching() scheduled the FSEvents stream on
dispatch_get_main_queue(), so the whole notification pipeline ran on the GUI
thread, unlike the Windows backend which uses its own WatcherThread. The work
done there is unbounded in the number of files:

• addCoalescedPaths() walked every reported directory's whole subtree with
  QDirIterator and deduplicated it with a linear QStringList::contains();
• notifyAll() — reached on kFSEventStreamEventFlagMustScanSubDirs or a
  kernel drop, which is exactly what a mass copy triggers — enumerated the
  entire sync folder and reported every path individually;
• each reported path then costs a journal lookup and several stats in
  Folder::slotWatchedPathChanged().

The setup case has a separate, cross-platform cause: SyncEngine::slotItemDiscovered()
kept _syncItems sorted with a lower_bound + QVector::insert per item, which
memmoves the tail every time and costs O(n²) overall, all of it on the GUI thread
before the first byte is transferred.

Changes

Four self-contained commits:

1. fix(macOS): handle file system events off the GUI thread — private serial
   dispatch queue, batches handed to the watcher's thread with a queued
   invocation; subtree expansion bounded and deduplicated with a QSet;
   notifyAll() asks for a full local discovery instead of walking the tree.
2. fix: keep a full local discovery request across a running sync — a request
   arriving mid-sync was silently dropped, because the running sync restarts
   _timeSinceLastFullLocalDiscovery when it finishes. This one is pre-existing
   and not macOS-specific, but the change above depends on the request being
   honoured.
3. perf: sort discovered sync items once instead of inserting in order — O(n²) → O(n log n).
4. perf: cache the selective sync list in the journal — it was queried once per added file.

Testing

Built on macOS (Qt 6) and run as the daily driver against a real server, on a
sync folder of ~84 GB.

• FolderWatcherTest, LocalDiscoveryTest, SyncJournalDBTest, SyncMoveTest,
  RemoteDiscoveryTest, SyncConflictTest, SyncFileStatusTrackerTest,
  AllFilesDeletedTest, BlacklistTest, SyncDeleteTest all pass. A debug
  build covers commit 3 through the Q_ASSERT(std::is_sorted(...)) in
  finishSync() and OwncloudPropagator::start().
• testMove3LevelDirWithFile in particular still passes: FSEvents does not
  report the items below a renamed directory, so the expansion is still needed --
  it is bounded, not removed.
• Manual: copied a folder of ~101k files / 13 GB into the sync folder. The window
  stayed responsive throughout, where it used to freeze. sample(1) on the main
  thread during discovery shows it parked in nextEventMatchingMask with no
  FolderWatcher/ProcessDirectoryJob frames on it.
• By accident this also got an A/B run: a stale login item relaunched the
  released 33.0.7 build alongside the patched one, against the same account and
  folder. Activity Monitor showed the released build as "Not Responding" while
  the patched one kept its main thread ~80% idle under the same load.

Notes for reviewers

• addCoalescedPaths() deliberately bounds only its own expansion, not the
  incoming batch: those are events FSEvents actually reported, they are capped by
  the kernel's own buffer, and reporting them drives things a full local
  discovery cannot redo, such as releasing office file locks.
• changesLost() reports no path on purpose. The watched root reaches the local
  discovery tracker as an empty relative path, and {""} matches only the root
  itself, not the tree below it — so it would look like a fix while quietly
  discovering nothing.
• The sync engine still runs on the GUI thread; this does not change that. It
  removes the unbounded single blocks, so the remaining work yields to the event
  loop between batches.

[claucambra]

Hi @ftapps how did you reproduce the issue before the fix and verify it worked after the fact? Would like to test on my own system

If possible it would also be good to formalise this into a proper test so we can guard against regressions on this :)