fix: abort sync on PermissionError to prevent destructive index reconciliation

[sanjibani]

Summary

• scan_directory(): raise SyncFatalError instead of returning on PermissionError
• _quick_count_files(): propagate SyncFatalError from scan_directory() fallback
• scan(): catch SyncFatalError from both _quick_count_files (count phase) and await scan_coro (full-scan phase), returning early without updating watermarks or triggering deletion reconciliation

Fixes GH#1007

When aiofiles.os.scandir() raises PermissionError on the project root, the sync now aborts immediately instead of representing the inaccessible root as an empty successful scan. This prevents the full_deletions strategy from deleting every indexed entity.

Test changes

• Updated test_scan_directory_raises_on_permission_error to expect SyncFatalError (subdirectory permission errors now propagate)
• Added test_sync_aborts_and_preserves_index_when_root_dir_inaccessible regression test

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[sanjibani]

recheck

[phernandez]

@sanjibani Thank you for digging into this and for adding a regression test. The underlying safety concern is absolutely valid: an unreadable project root or subtree must never look like an empty successful scan and trigger destructive deletion reconciliation.

Since this PR was opened, #1054 merged a replacement for the old SyncService scan path. The new local project indexer now aborts an unreadable root scan, carries indexed files through unreadable subtrees or transient read failures, and only treats a file as deleted when its absence is confirmed. Because the code this patch changes has now been removed from main, there isn't a useful rebase path for this implementation.

I'm closing this as superseded, not rejected—the report and test scenario were useful and align with the safeguards now on main. Thanks again for the contribution.