fix(auth): measure Windows keychain limit in UTF-16 bytes and clear stale entry on fallback

[phil-accelbyte]

Problem

The Windows Credential Manager guard measured the token blob with UTF-8 str::len() against the 2560-byte limit, but keyring's windows-native backend stores the password as a UTF-16 blob and rejects values whose UTF-16 byte length exceeds 2560. For ASCII that guard is 2× too lenient: a token JSON of ~1281–2560 chars passed the check, reached the keychain, failed the write, and silently fell back to file storage while leaving the old keychain entry in place.

Reads are keychain-first, so the stale entry shadowed the fresh file token — its rotated refresh token was then sent on the next refresh and the server rejected it (Session expired and token refresh failed). Windows-only; it surfaced as token JSONs grew past ~1280 chars.

Fix

• Measure the blob via credman_blob_bytes (UTF-16 bytes), matching keyring's own check.
• Clear any stale keychain entry on every file-storage fallback (not just the over-limit branch) so it can never shadow the file token on a later read.

Tests

• credman_blob_bytes is twice the ASCII length.
• A 1300-char token sits in the UTF-16 "dead zone" (UTF-8 under the limit, UTF-16 over) and now trips the guard.
• File-fallback round-trip: the refresh token survives storage and reads back unchanged.