Correct Remote Change Propagation to File Provider Framework - #10252

Community and paying-support reports describe server-side changes that intermittently fail to appear in the macOS File Provider domains, with no reliable reproduction. This PR pins down three concrete derivation bugs in the file-provider extension that silently drop remote changes, fixes them, and adds deterministic reproducers. Scope is macOS File Provider only (Windows / Linux / classic sync folders are unaffected).

The branch has two logically separate commits and can be reviewed (or split) accordingly:

1. Fix: remote changes silently dropped during working-set change enumeration

Because a change notification only ever signals .workingSet, working-set change enumeration is the path that drives remote updates into the framework. Three issues there caused changes to be discovered but never reported:

• Depth-1 / non-materialised subtrees. The materialised-items scan read each visited folder only one level deep and never recursed into changed subdirectories, so a change to an item under a non-materialised subfolder surfaced the subfolder but never the item — even when the server propagated ETags correctly. The scan now walks a work queue that descends into changed subdirectories, while still skipping unchanged subtrees (the existing optimisation is preserved).
• Discovered-but-discarded changes. The scan persisted discovered changes to the database but the report was then reconstructed purely from a syncTime > anchor query, which excludes non-materialised items and items whose parent directory did not itself change. The scan now returns the discovered creations/updates/deletions, which are reported directly, merged and de-duplicated with the database-derived pending local changes.
• Content change with unchanged ETag. isInSameDatabaseStoreableRemoteState did not compare size, so a content change carrying a stale/unchanged ETag + date was treated as "no change." It now also compares size.

Adds RemoteChangePropagationTests — deterministic reproducers driven through the real working-set path via the existing mock harness. Three reproduced the drops above and now pass as regression guards; one documents that the notify_push fileId gate correctly matches on the parent folder id (the server propagates the changed ETag up to the user's root, so the gate is not a source of dropped new items — see #6430).

2. Refactor (behavior-preserving): make the enumerator legible

No behavior change — guarded by the unchanged, fully-passing test suite:

• Replaced the positional 6-tuple returned by readServerUrl with a named RemoteReadResult, and the three parallel new/updated/deleted arrays with a ChangeSet value type.
• Split the ~850-line Enumerator.swift (now ~135 lines) into focused, documented Enumerator+*.swift extensions by concern (item enumeration, change enumeration, working-set scan, observer reporting, sync anchor; trash beside the existing trash code). The two NSFileProviderEnumerator methods are now thin dispatchers.
• Renamed opaque locals and checkMaterializedItemsOnServer → scanMaterialisedItemsForRemoteChanges; added doc comments throughout.

Checklist

• Sign-off message is added to all commits.
• The commit history is clean with no merge commits.
  • How to rebase your commits
  • How to squash commits with rebase
• Uploaded screenshots from before and after for UI changes.
• Documentation has been updated or is not required.
• Backports requested where applicable (critical bugfixes).
• Labels added where applicable (bug/enhancement).
• Milestone added for target version.

AI (if applicable)

• The content of this PR was partly or fully generated using AI
  • I have read the guidelines for AI-assisted contributions.
  • I have read Nextcloud's AI Contribution Policy.