fix(file-provider): Correctly enumerate large change batches

[claucambra]

Resolves

#10556

Summary

We had issues with the batched change reporting in the enumerator.

1. We needed to change the anchor in between change batches in order for moreComing to be respected by the system (and for further changes to be requested by the system)
2. These intermediate anchors need to survive outside of the enumerator instance used for the initial change enumeration, as the system creates a new enumerator per batch

Issue Reproduction

The unchanged-anchor bug reproduced successfully.

• Baseline folder was empty and visited.
• With client and extension stopped, 205 files were uploaded successfully.
• After restart, the extension derived 207 updates: 205 files plus the root and test folder.
• It reported 200 updates, retained seven, and returned moreComing: true.
• Subsequent scans restarted from the identical anchor instead of delivering the seven-item continuation.
• Finder’s File Provider mount contained only 198 of the 205 files. The missing files were item-122.txt through item-127.txt, plus item-191.txt.
• All seven missing files returned HTTP 200 from the server.
• No 502 occurred, and there were zero File Provider errors before cleanup.

The current macOS version did not retain the literal “token is unchanged” message, but the daemon’s anchor remained unchanged and no updated: 7, moreComing: false batch occurred. The behavior is therefore confirmed directly.

Checklist

• Sign-off message is added to all commits.
• The commit messages are following The Conventional Commits specification.
• 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.
• Test(s) added to branch, with before/after results included in PR description, for performance improvements where applicable.
• 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.

[Rello]

tested on my side

• 205 server files were discovered as 207 updates.
• First batch: 200, moreComing: true.
• macOS created a fresh Enumerator using fp-continuation|…|200.
• Final batch: 7, moreComing: false.
• Finder contained all 205 files: 0 missing, 0 extra.
• A subsequent server file also appeared, proving later changes still propagate.
• No 502 responses, incomplete scans, or errors occurred before cleanup.

[claucambra]

/backport to stable-34.0 please

[i2h3]

Argh… The framework always is good for surprises like these. The best part: it can change any time. 🙄

[i2h3]

It is a bit odd wording, I would have used the conventional "persistent" because "durable" sounds more like bicycle tires. 😅 Not an issue, though.

[github-actions]

Artifact containing the AppImage: nextcloud-appimage-pr-10660.zip

Digest: sha256:9f97f2a84f705d527495203d47c7402a6125f6999ab34e4ac881424dbdebe8ad

To test this change/fix you can download the above artifact file, unzip it, and run it.

Please make sure to quit your existing Nextcloud app and backup your data.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud