# 2.1 session revocation and fresh authorization

This changes source behavior for audit H-6 and the HTTP boundary for H-5.
Source regression and installed-node/manual acceptance are separate. No live
credentials, pairings, wallets or releases are changed by this branch.

## Remembered browser families

A remember credential is a random 256-bit opaque value. Only its hash is stored,
with the associated full sessions, in one mode-0600 atomic, synced session file.
Explicit logout removes that browser family and every session restored from it;
other browsers remain signed in. The browser also expires its session, CSRF and
remember cookies. A request restored immediately before logout cannot append a
new cookie after the deletion. Storage failures refuse revocation rather than
claiming success.

Password and TOTP changes durably revoke other sessions and every remember
credential before changing configuration, then rotate the caller. Device-token
revocation/replacement removes associated sessions. A device login carries one
verified credential snapshot through cookie creation; it cannot become an
unbound password login because a second verification fails. Its remember family
is bound to the device name and credential hash and checks current scope,
expiry and replacement on validation/restoration, including after restart.

Restoration preserves the family's original authentication time. The configured
absolute lifetime applies across restoration, independent of polling or idle
expiry. Restart loads the configured idle/absolute policy and device class.
Idle activity between session mutations remains in memory; restart can therefore
conservatively expire an idle session earlier, but cannot extend its hard cap.

The old stateless timestamp/HMAC remember cookie and unbound v1 persisted
sessions are not accepted. Existing browsers sign in once after upgrade; no
identity, paired-device credential or application data is deleted.

## Concurrent authentication

The same transition also covers every onboarding identity/seed operation and
setup/completion, so an admitted pre-setup export, signature or identity creation
cannot continue across provisioning. Handler gates remain in place.

Dashboard and app-gate password/TOTP transitions share a mutex with credential
changes through session/cookie creation. Pending TOTP retains the encrypted
configuration it was verified against, and the atomic consumer checks that
configuration is still current. TOTP steps and backup codes cannot be consumed
by concurrent requests twice. Failed account/TOTP reads refuse login instead of
falling back to password-only access. User-record mutations use synced atomic
replacement so readers cannot observe a truncated account record.

Signer approval polling holds no credential-transition lock. Once approval
arrives, login rechecks the current enrolled identity and linked key, plus the
current TOTP configuration for password-pending sessions, before minting. Cookie
creation validates that exact minted token again under the transition; missing
or revoked tokens never cause a replacement session to be created.

Signer enrollment workers return approval without changing the account. Final
enrollment requires the initiating session, unchanged password/TOTP/role state,
current linked key and uncancelled identity generation. Removing a signer or
deleting its identity cancels pending enrollment. Enrollment and removal also
require the central fresh-password/TOTP proof.

## Fresh operation boundary

Only an explicit pre-dispatch refusal carries RPC error `-32041`. Fresh proof
is checked before any protected handler runs. App-credential proof protects
`package.credentials-authorize`; its short, one-use capability is created after
the human prompt and then redeemed by `package.credentials`. Handler failures
retain ordinary error codes and cannot trigger an automatic payment retry.
Assistant tool confirmation cannot authorize protected funds/signing/export
operations; both curated internal bridges explicitly refuse those methods.

The focused regression sources exercise real HTTP cookies, rejected CSRF,
restoration/logout ordering, durable failures, password/TOTP changes, device
replacement/expiry, restart policy, queued credential races, and capability
mint/redemption. Results must come from `scripts/test-backend-isolated.sh`;
these source assertions alone are not installed-node acceptance.