Re-authorize a credential in place

[ppXD]

Summary

• Re-authorize a credential in place. A reconnect used to mint a new credential row, so repositories, group hooks and the act-as identity pointed at a dead row until a succession subsystem moved them. The new token is now written into the same row, so nothing moves and nothing can be left behind.
• OAuth: InitCredentialOAuthCommand.ReplaceCredentialId is kept on the pending state (migration 0250, nullable and additive) and the callback hands the token to the new ICredentialReauthorizer instead of creating a row. Pasted tokens: PUT /api/credentials/{id}/token probes the token at the provider, within the same probe deadline the health sweep keeps, then does the same write.
• The reauthorizer takes the lock a refresh takes (the in-process semaphore, then the Postgres advisory lock, extracted into CredentialRefreshLock), re-reads the row under it, and writes payload, auth type, scopes, expiry and name in one compare-and-swap that also sets the row Active, clears its last error and stamps LastValidatedDate.
  • A refresher can neither rotate the pair being replaced nor write its own over the new one. A rotated pair this process kept because it could not store it is dropped under the same lock, so it cannot be stored over the new authorization later.
  • A Disconnect or retirement that lands mid-write is read again or refused, never undone (deleted_date IS NULL and the expected payload both guard the swap).
  • It then revives the Error repositories and Failed/DeadLettered group hooks bound to the row, relinks the owner's act-as identity, and after the commit asks the provider to revoke the replaced tokens only, never the whole grant.
• It leaves the row saying what is true of the new token, which is what credential health reads. A credential its provider had refused (Error) is Active again at once; a static token carries the expiry the provider reports for the new token and not the lapsed one's, so the list derives health (active, or expiring with daysToExpiry) without waiting for a sweep. No row is created, so the connect-time rule that carries a refused credential's bindings to a new one never fires. A sweep's or refresher's verdict about the replaced token that lands afterwards is a compare-and-swap on a payload the row no longer holds and changes nothing.
• The sign-in must be the same provider account the credential was connected as, otherwise it is refused with credential_account_mismatch.
  • The account on record is the one the act-as identity naming the credential holds. When a newer connect re-pointed that one identity at another credential of the same person, it is the account the person's identity speaks for on that instance.
  • A team-service credential, or a person with no identity, has nothing to compare, and the identity linked now records the account.
• A credential retired as its person left or its connection was removed stays retired (credential_retired).
• Connecting without ReplaceCredentialId behaves exactly as before.
• Rolling deploy: an older pod that completes a pending row naming a credential ignores the column and creates a new row, as it always did. A pod from before 0250 inserts rows with NULL, which every version treats as a plain connect. Rolling back is a git revert; the column is nullable, has no foreign key, and is ignored by the previous build.
• The Providers modal gains Reconnect (OAuth) and Replace token, keeps a credential the provider refused in its list, and shows what its health says: needs reconnect, needs a new token (also for a token that lapsed while its row was still Active), or how many days a token has left, on personal and team tokens. The Settings Providers summary says "needs reconnect" for a refused credential instead of "not connected". health and daysToExpiry are optional on the client, so a new SPA on an older API still marks status: "Error" credentials.

Test plan

• Unit (full): 14582 passed, 1 skipped. Covers the shared recorded-expiry rule for a static token (described, never expires, not described, OAuth, no probe).
• Integration (CredentialReauthorizationFlowTests, 55): the id is kept, and repositories, hooks and identity come back intact; replaced tokens are revoked at token level only; a different account, a departed or retired credential are refused; concurrent refresh, another process of either build and racing reconnects are serialised; pre-0250 pending rows still complete.
• Integration, interplay with credential health: a grant the refresher refused for good is reconnected in place, reads Active at once and a run resolves; replacing a lapsed token (row Error, or still Active) reads as the new token does (active, expiring in 10 days, never expires); a sweep verdict about the replaced token, rejected or validated with the old expiry, that lands after the replacement writes nothing; a refresh waiting behind a re-authorization never presents the dead grant; a pair kept for the replaced grant is not stored over a shorter-lived new authorization; a re-authorization moves nothing that hangs on another refused credential while a plain connect still does; a silent provider costs a pasted token its probe deadline and changes nothing.
• Integration, related suites: Credentials, OAuth 358 passed; Providers, ProviderInstances, Binding, Repositories, Health, Hangfire, Webhooks, PullRequestTriggerAdmission 365 passed.
• E2E through HTTP (Credentials, Auth, Repositories: 199 passed), including the cross-site completion path, PUT /token, and GET /api/credentials reading rejected before and active after, with the new token's expiry.
• Frontend on Node 22: lint (0 errors), tsc --noEmit -p tsconfig.app.json, vitest 2613 passed (modal chips for refused, lapsed, expiring and team tokens; Settings summary), build.
• Each new guard was checked by mutation to fail when removed.
• After deploy: watch credential_account_mismatch volume for a person who holds two different accounts on one instance. Those people are refused conservatively and connect the other account as its own credential.
• After deploy: confirm a pair kept in another pod's memory never wins over a re-authorization (the existing later-expiry rule decides that case).