#3136 serve: token secret migration repoints a token even when copying its OAuth access token failed

Description

migrateOne in src/serve/token_secret_migration.ts copies a token's OAuth access token from the user vault to _token-secrets inside a catch that treats any failure as a missing key. It then repoints the record's vaultName to _token-secrets regardless. If the read failed for a transient reason and the key survives in the user vault (the vault has no delete, or the delete also fails), the token is left half migrated: its record names _token-secrets but its OAuth access token is only in the user vault.

Since the fix for swamp-club#3127 (PR 2896), the collective refresh no longer falls back to the user vault for a record that names _token-secrets. Such a token is therefore never refreshed. A userinfo 401 no longer revokes it, so a deprovisioned user's token stays active until it expires. The boot log reports the token as migrated and nothing is logged above debug.

Steps to reproduce

Observed end to end on a build of commit 362a1ce1 with a file-backed test vault that has no delete support.

1. Mint a server token whose record names a user vault, and put its oauth-access-token key in that vault.
2. Make reads of oauth-access-token keys in that vault fail, then start serve in OAuth mode so the boot migration runs.
3. Restore the vault and make the provider return 401 from userinfo for that user.
4. Wait for a collective refresh cycle. No userinfo call is made and the token stays active.

Expected

A key that is present but fails to copy should not be treated as absent. List the vault first, as migrateOAuthSecrets does, and skip the repoint and delete for that token so the next start retries.

Exposure

OAuth-login tokens live 30 days by default and the migration shipped on 2026-08-04, so this needs an older token kept alive by rotation, or a direct upgrade from a build before swamp-club#1511, plus a vault fault during migration. Records an older build already left in this state are affected too.