File changes in shared folder do not appear locally

### ⚠️ Before submitting, please verify the following: ⚠️

- [x] This is a **bug**, not a question or a configuration issue.
- [x] This issue is **not** already reported on Github (I've searched it).
- [x] Nextcloud Server and Desktop Client are **up to date**. See [Server Maintenance and Release Schedule](https://github.com/nextcloud/server/wiki/Maintenance-and-Release-Schedule) and [Desktop Releases](https://nextcloud.com/install/#install-clients) for supported versions.
- [x] I agree to follow Nextcloud's [Code of Conduct](https://nextcloud.com/contribute/code-of-conduct/)

### Bug description

The File Provider Extension intermittently reports `account not set up` after a fresh account setup on 33.0.2. This causes certain container enumerations (e.g. Trash) to fail, while others succeed with the correct account context.
This appears to be a regression or incomplete fix of #9393, which was closed for the 33.0.0 milestone. The issue persists on 33.0.2 with a completely fresh installation (no upgrade/migration from older versions).

Key observations from the File Provider Extension debug logs:

- `"Not providing enumerator for container with identifier [...] yet as account not set up"` appears repeatedly — both for trash container and for specific file item identifiers.
- Other enumerations in the **same session** succeed and correctly resolve the account (e.g. "Set up enumerator." with full account and DAV URL).
- maybe a timing/race condition: the extension starts enumerating before the account is fully initialized. Some enumerations hit the uninitialized state, while later ones succeed.
- Trash-related operations also fail: `"Did not find trashed item in trash, asking for a rescan" `followed by `"Tried to modify filename of already trashed item. This is not supported."`

**Practical impact:** Changes made by other users in shared folders are not reliably reflected in Finder via VFS. The Nextcloud client activity feed shows the changes correctly (notify_push is active and working), but the File Provider Extension does not propagate them to the file system.

### Steps to reproduce

1. Fresh install of Nextcloud Desktop Client 33.0.2 on macOS (no prior installation/migration).
2. Add an account connected to a Nextcloud server (managed Hetzner StorageShare in my case).
3. Let VFS / File Provider Extension complete initial enumeration (~500 GB, many files).
4. Observe debug logs: account `not set up errors` appear for some container enumerations.
5. Have another user modify or add files in a shared folder.
6. Changes do not appear in Finder. Client activity feed shows the changes correctly.
7. Removing and re-adding the account temporarily helps, but the problem returns within ~2 days.

### Expected behavior

All container enumerations should use the fully initialized account context. Server-side changes detected via notify_push should be reflected in Finder via the File Provider Extension.

### Which files are affected by this bug

All files managed by the File Provider Extension / VFS.

### Operating system

macOS

### Which version of the operating system you are running.

Sequoia 15.7.5

### Package

Official macOS 12+ universal pkg

### Nextcloud Server version

32.0.6

### Nextcloud Desktop Client version

33.0.2

### Is this bug present after an update or on a fresh install?

Fresh desktop client install

### Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

### Are you using an external user-backend?

- [x] Default internal user-backend
- [ ] LDAP/ Active Directory
- [ ] SSO - SAML
- [ ] Other

### Nextcloud Server logs

```shell
N/A — managed instance, no server log access.
```

### Additional info

- notify_push is active and working (changes appear in the client’s activity feed).
- ~500 GB of data, heavy VFS usage.
- The account has been removed and re-added multiple times; the problem consistently returns.
- Related: #9393 (closed for 33.0.0 milestone).
- Related: #9846 the triangle is also showing in the client icon. and similar #8694
- Debug archive available on request (contains file names from a shared workspace — prefer not to post publicly).
- an option like "Force re-enumerate" would be good for similar problems in the future

UPDATE 16.04.2026
A related issue: When a shared folder is moved to a different location via the web interface, the File Provider Extension continues to enumerate the old path and fails with NKError code 1. The new location does not appear in Finder.
Log excerpt:
```shell
"Set up enumerator." (with old path)
"Read of URL did fail." — NKError code 1
"Finishing enumeration for page with error."
```
Using "Remove Download" on the parent folder in Finder and restarting the client does not resolve this — the moved folder still does not appear at its new location.
It seems the File Provider Extension does not process server-side move/rename operations for shared folders during change observation.