Desktop client (33.0.5–33.0.7) intermittently sends a random client-generated GUID as Basic-Auth username instead of the stored login/app-password

### ⚠️ 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

## Bug description

On a Nextcloud server with ~5900 accounts (external auth backend, IMAP), we are seeing a continuous, low-level stream of failed WebDAV authentication attempts originating from the official desktop sync client. Server-side logs show the client periodically sending a **locally-generated GUID/UUID string** (wrapped in curly braces) as the Basic-Auth **username**, instead of the real account login name — on the *same* endpoint, from the *same* client instance, that at other times successfully authenticates using the correct stored app-password/token.

This is not a one-off: it repeats roughly every 24–30 seconds per affected account, indefinitely, and affects many different user accounts across our instance.

## Environment

- Server: Nextcloud 32.0.9.2 (Linux, nginx + PHP-FPM), external auth backend (`user_external`, IMAP)
- Affected desktop client versions (confirmed in server logs): **33.0.5, 33.0.6, 33.0.7**
- **Not observed on any client version prior to 33.0.5** (verified across ~2 months of centralized logs)
- Platforms affected: **both Windows and macOS** (Apple Silicon, macOS 15.x) — including a **brand-new, clean install of 33.0.7 on macOS**, installed 2 days prior to observation, ruling out a stale/corrupted local credential store as the sole cause
- First occurrence in our logs: **2026-06-09 12:16:56 CEST** — consistent with gradual client auto-update rollout after 33.0.5's release (2026-05-19)

## Observed behavior (server-side log evidence)

Example (anonymized), two requests from the **same account**, **same client**, **same IP**, ~35 seconds apart — one uses a GUID as username, the surrounding successful requests use the real app token:

```
2026-07-03T09:35:02+02:00 PROPFIND /remote.php/dav/files//
userAgent: Mozilla/5.0 (Macintosh) mirall/33.0.7 (Nextcloud, macos-15.x ClientArchitecture: arm64 OsArchitecture: arm64)
message: Login failed: '{10f8b3ec-c693-4931-8cd1-267cabcab3f0}' (Remote IP: 'xx.xx.xx.xx')
clientReqId: 273246ef-8b31-41ca-a730-ec9486581a08

2026-07-03T09:35:37+02:00 PROPFIND /remote.php/dav/files//
userAgent: Mozilla/5.0 (Macintosh) mirall/33.0.7 (Nextcloud, macos-15.x ClientArchitecture: arm64 OsArchitecture: arm64)
message: Login failed: '{11f3c94a-6a8f-4a1b-a537-c988461db8a8}' (Remote IP: 'xx.xx.xx.xx')
clientReqId: 7b5b6c96-c668-4922-a133-1bf555aec6ca
```

Notes on the pattern:
- The GUID sent as username is **different on every attempt** (not a fixed, cached bad value) — this rules out a simple "one corrupted keychain entry" explanation.
- The GUID is **not** the same as the request's own `clientReqId` (so it isn't simply a correlation-ID field leaking into the wrong header).
- The server's `oc_authtoken` table shows the **same account** has legitimate, recently-refreshed app tokens (`login_name` = real account name, type = permanent) being used successfully around the very same time — so the client clearly *has* a working, valid stored credential, but on some fraction of requests something else (a race condition on the credential-read path, we suspect) substitutes a freshly-generated internal UUID for it instead.
- Across a ~2.5 hour sample window we captured **1181 such failed attempts from `mirall` clients alone**, spread across roughly 10+ distinct accounts, all client versions 33.0.5–33.0.7.
- No occurrence of this pattern was found in the same centralized logs for the ~6 weeks preceding 2026-06-09, nor for any client version below 33.0.5.

## Impact

- Continuous unnecessary authentication load against our (external, IMAP-backed) auth provider — every failed attempt is a fresh TLS/IMAP handshake.
- Confusing/misleading server-side security logs (looks like credential stuffing / brute force from legitimate corporate IPs).
- Anecdotally correlates with users reporting their desktop client repeatedly "logging them out" / failing to sync.

## Expected behavior

The client should always use its correctly stored account credential (app password / token) for Basic-Auth, and never substitute an internally-generated UUID/GUID for the username field, regardless of any internal retry/backoff/race condition.

## Steps to reproduce

We do not yet have an isolated local reproduction (this was found via centralized server-side log analysis across many managed corporate endpoints). We're filing this primarily to share concrete server-side evidence, in case it matches a known race condition in the credential-handling code introduced between 33.0.4 and 33.0.5. Happy to provide additional anonymized log samples, timing data, or help correlate with specific commits between those two releases if useful.

## Additional context

- We can provide the diff of `mirall` versions/commits between 33.0.4 and 33.0.5 ourselves if it helps narrow this down — flagging here in case anyone recognizes the pattern (e.g. a credential-manager read racing with a retry/backoff timer, or a fallback path that mistakenly generates a UUID when a credential fetch is momentarily unavailable).
- Happy to share more (anonymized) log excerpts or timing statistics on request.

### Steps to reproduce

I dont know

### Expected behavior

fix in next version

### Which files are affected by this bug

this is not a file, its desktop application

### Operating system

Windows

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

Windows 11, macos Tahoe 26.5.1

### Installation method

Official Installer for macOS 13 and later

### Nextcloud Server version

32.0.9.2

### Nextcloud Desktop Client version

33.0.5 33.0.6 33.0.7

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

Clean desktop client installation

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

Yes

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

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

### Nextcloud Server logs

```shell

```

### Additional info

im using user_external 4.0.0 and sync with mail server using IMAP connection.

Start by comparing the mirall 33.0.4 and 33.0.5 changes, focusing on credential handling and retry paths across the affected Windows and macOS clients. Use the supplied server logs and version range to establish a reproducible case; done means the client consistently sends the stored account credential and no longer emits GUID usernames.

Written by the indexing model from the issue text.