bug: a wallet backup that hits a busy paykit lock is not retried until the next change #1550

Refs:

• bug: pubky sign-in link can still time out on cold start while paykit holds the shared-state lock #1541
• fix: open pubky sign-in links while the session restore is deferred #1543

What happened?

A wallet backup that runs while the Paykit shared state is locked fails with shared_state_busy, is logged at ERROR, and is not retried in that session. @jvsena42 saw it during the device test of #1543 (review):

BackupRepo.kt:600 Backup failed for: 'WALLET' … shared_state_busy

The WALLET snapshot reads Paykit state (privatePaykitRepo.backupSnapshot()), which needs the shared-state lock. markBackupFailed then records the failed required value, and shouldBackup skips the category until a new change marks it required again.

No backup is lost: the required status is persisted, so the next WALLET change or the next app start retries it, and the backup failure toast shows after 30 minutes if it is still pending. Until then the latest wallet state has no backup.

Expected behavior

A wallet backup that fails with a temporary Paykit error (shared_state_busy, concurrent_update) is retried with a backoff in the same session, and the failure is logged as a retry at WARN, not ERROR. Other failures keep the current handling.

Steps to Reproduce

1. Create a Pubky profile on staging.
2. Force-stop Bitkit and open a fresh pubkyauth://signin_grant link at once; repeat until the log shows Deferred session restoration … shared_state_busy.
3. Make a wallet change that needs a WALLET backup while the shared state is locked.
4. Observe Backup failed for: 'WALLET' at ERROR and no further WALLET backup attempt until another change or a restart.

Additional context

Found while checking whether the busy lock can skip a backup for good (it cannot).