Windows: Navigation pane entries are removed at every client startup and never re-created (registry update runs before folders are loaded)

### ⚠️ 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 have searched for 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

## Description

On Windows, the Explorer navigation pane entries for synced folders ("Show sync folders in the Explorer navigation pane" = enabled) are **removed at every client startup and never written back**. The Nextcloud folder disappears from the Explorer navigation pane after each Windows reboot / client restart, even though the setting is enabled and the client is running.

## Environment

- Client version: **34.0.3 (build 20260826)**
- Operating system: Windows 11 Version 25H2
- Sync folder: `C:\Users\\Nextcloud` (classic sync, **no** virtual files / VFS)
- Toggle `showInExplorerNavigationPane=true` in `nextcloud.cfg` (persisted, unchanged across restarts)
- The folder's `navigationPaneClsid` is persisted in `next.cfg` (`0\Folders\1\navigationPaneClsid=…`) and does **not** change across restarts.

## Actual behavior

The client **deletes** its existing namespace entries at startup but **never re-creates them**.

Client log (`%APPDATA%\Nextcloud\logs\…_nextcloud.log.0.gz`, complete startup session, 22k+ lines):

```
14:54:12.173 [ info nextcloud.gui.folder.navigationpane …\navigationpanehelper.cpp:161 ]:
Explorer Cloud storage provider: now unused, removing own CLSID "{16f4a9d0-1df9-4035-adbf-dcba2381e791}"
```

That is the **only** `navigationpane` log line of the whole session. There is **no**
`Explorer Cloud storage provider: saving path … to CLSID …` line, i.e. `updateCloudStorageRegistry()`
performed the removal pass but never reached the save pass.

Registry state after client startup (HKCU):

- `Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\NameSpace\{…}` – **missing** (was removed)
- `Software\Classes\CLSID\{…}` – orphaned leftover of an older GUID generation (no namespace link)

## Root cause analysis

In `src/gui/navigationpanehelper.cpp`:

1. The `NavigationPaneHelper` constructor schedules an initial
`updateCloudStorageRegistry()` run ("Ensure that the folder integration stays persistent in
Explorer, the uninstaller removes the folder upon updating the client.").
2. `updateCloudStorageRegistry()` walks all `Desktop\NameSpace` sub keys and marks **every** entry
with a matching `ApplicationName` for removal, then re-saves only the folders currently present
in `FolderMan`'s folder map:
`for (const auto &folder : _folderMan->map()) { if (!folder->navigationPaneClsid().isNull()) … }`
3. At client startup the scheduled run fires **before the folders are loaded** into
`FolderMan`'s map (accounts/folders are restored asynchronously). The removal pass therefore
deletes the old entries, the save loop iterates over an **empty folder map** and writes nothing.
The 500 ms single-shot timer is never re-armed afterwards, so the entries are never restored.

This matches the log exactly: one "removing own CLSID" line, zero "saving path" lines.

## Suggested fix

One of the following:

- **Re-schedule after folders are loaded:** call
`NavigationPaneHelper::scheduleUpdateCloudStorageRegistry()` once `FolderMan` has finished
loading/restoring the folder list (e.g. at the end of `FolderMan::setupFolders()` /
after accounts are restored), instead of (or in addition to) scheduling it in the constructor.
- **Guard the removal pass:** in `updateCloudStorageRegistry()`, skip the removal of existing
entries when `_folderMan->map()` is empty (folders not yet loaded) and re-schedule the update
instead of performing a destructive pass with incomplete state.

## Workaround (what we use meanwhile)

A PowerShell script that reads the per-folder `navigationPaneClsid` from `nextcloud.cfg`
(QSettings `@Variant` QUuid blob), re-creates the full MSDN "Cloud storage provider – navigation
pane" registry set (steps 1–12, incl. `Wow6432Node` and `HideDesktopIcons`) for exactly that CLSID,
and sends `SHChangeNotify(SHCNE_ASSOCCHANGED)` so the running Explorer picks it up.

Note: registering the **config-persisted** CLSID is what makes the workaround durable – the
client's startup cleanup only removes entries whose GUID does not match a folder's persisted
`navigationPaneClsid`. Also worth mentioning: the client never calls `SHChangeNotify`, so even
when the entries are written correctly, a running Explorer instance only shows them after a
restart of the Explorer process (or an external `SHChangeNotify`).

## Additional context

- The behavior is 100 % reproducible on this machine across multiple reboots.
- Toggling the setting off/on "fixes" it temporarily because that path runs
`updateCloudStorageRegistry()` while the folder map is populated.

### Steps to reproduce

## Steps to reproduce

1. Enable "Show sync folder in Explorer navigation pane" in the client settings.
2. Verify the folder is visible in the Explorer navigation pane.
3. Reboot Windows (or exit and restart the client).
4. Open Explorer → the Nextcloud entry is gone.

### Expected behavior

## Expected behavior

After client startup with the toggle enabled, the `Desktop\NameSpace` and `CLSID` registry entries for the sync folder exist and the folder is visible in the Explorer navigation pane.

### Which files are affected by this bug

src/gui/navigationpanehelper.cpp and src/gui/folderman.cpp

### Operating system

Windows

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

Windows 11 25H2

### Installation method

Official Linux AppImage

### Nextcloud Server version

33.0.8

### Nextcloud Desktop Client version

34.0.3

### Did this occur after an update or on a clean installation?

Minor version update (i.e. 33.0.0 → 33.0.1)

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

No

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

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

### Nextcloud Server logs

```shell

```

### Additional info

_No response_

Start in src/gui/navigationpanehelper.cpp by reading the constructor, scheduleUpdateCloudStorageRegistry(), and updateCloudStorageRegistry(), then trace folder loading in src/gui/folderman.cpp, especially setupFolders(). Confirm the update cannot remove entries before FolderMan is populated; done means enabled sync folders retain their Explorer navigation-pane entries after a client restart.

Written by the indexing model from the issue text.