DPoP: key rotation is manual — a key lives until the integration is removed

The second named residual from #298 (INV-15), after the server-nonce gap.

Today

A DPoP keypair is minted at credential-save time and lives untouched until the credential is deleted (extension/peerd-egress/dpop/keys.js, fetch/origin-credential-routes.js). Rotating one means: remove the integration, re-add it, then re-register the new jkt with the provider by hand.

Why it matters

Non-extractability means the key cannot be stolen, but it does not mean the key should live forever:

• Use, not exfiltration, is the residual (INV-15). A compromise window is bounded by how long the key stays valid. With no rotation, that bound is "until the user notices".
• A stable jkt is a stable identifier the server sees on every request, for the life of the integration.
• If a server ever revokes or distrusts a thumbprint, peerd's only recovery is a manual delete/re-add cycle that also drops the access token.

Shape of the work

• A rotate operation that mints a new keypair and surfaces the new jkt without destroying the credential, so the user can register the new thumbprint before the old key retires.
• The ordering is the whole problem: the provider must accept the new jkt before the old key stops being used, or the integration breaks mid-rotation. Consider carrying two keys briefly (mint → surface → user confirms registration → retire old), rather than a hard swap.
• Optional: an age hint in Settings → API integrations so a stale key is visible.
• Whatever lands must keep the #298 lifecycle invariants intact — notably that a transient IDB read failure is not treated as "key absent" (that distinction is what stops a silent rotation from invalidating a still-live server-bound token).

Not a blocker for

Any 1.0 claim, in my read — this is lifecycle polish on a credential rung most integrations do not yet reach. Filed so it does not get lost.

Read extension/peerd-egress/dpop/keys.js and fetch/origin-credential-routes.js first, then trace the lifecycle invariants from #298. Use the issue's mint, surface, confirmation and retirement ordering to define the design; done means rotation preserves the credential and access token while allowing provider registration of the new jkt before the old key retires.