WinVaultKeyring backend does not always accept case-insensitive usernames

**Describe the bug**
The WinVaultKeyring backend does not always accept case-insensitive usernames, even when Win32Cred does.

The following function causes this inconsistency:
https://github.com/jaraco/keyring/blob/38c040133559682902f25fe96496756ee6849820/keyring/backends/Windows.py#L102-L110

The code checks if the service exists in the Windows Credential Locker with an exact, case-sensitive match of the username (`res['UserName'] != username`). If it's not found, either because it doesn't exist or because the casing is different, it looks up the compound name `{username}@{service}`, which completely skips username comparison.

**To Reproduce**
```powershell
> keyring set test USER
Password for 'USER' in 'test':
> keyring get test USER
PASS
> keyring get test user
> keyring set test user
Password for 'user' in 'test':
> keyring get test user
pass
> keyring get test USER
PASS
> keyring get test usER
PASS
> keyring set test usER
Password for 'usER' in 'test':
> keyring get test usER
paSS
> keyring get test USER
pass
> keyring get test user
pass
```

**Expected behavior**
WinVaultKeyring should use consistent case sensitivity.

**Environment**

- OS: Windows

```
> pip list | Select-String "keyring"
keyring 25.7.0
> keyring --list-backends
keyring.backends.chainer.ChainerBackend (priority: -1)
keyring.backends.fail.Keyring (priority: 0)
keyring.backends.Windows.WinVaultKeyring (priority: 5)
```

Start with keyring/backends/Windows.py at lines 102-110, then run the PowerShell reproduction against WinVaultKeyring. Trace the exact username comparisons and verify that get and set behave consistently across different username casing.

Written by the indexing model from the issue text.