fix: distinguish backup restore I/O errors from passphrase failures

[mvanhorn]

First time contributor checklist

• I have read how to contribute to this project
• I have signed the Contributor License Agreement

Contributor checklist

• I am following the Code Style Guidelines
• I have tested my contribution on these devices:

• Device A, Android X.Y.Z
• Device B, Android Z.Y
• Virtual device W, Android Y.Y.Z

• My contribution is fully baked and ready to be merged as is
• I ensure that all the open issues my contribution fixes are mentioned in the commit message of my first commit using the Fixes #1234 syntax
  Not run: no test command resolved in this workspace, so nothing was executed to pass.

---

Description

Add a distinct FAILURE_PASSPHRASE_VALIDATION result to RestoreRepository.BackupImportResult and return it only at the existing false result from FullBackupImporter.validatePassphrase; keep IOException mapped to FAILURE_UNKNOWN and retain the logged exception and finally cleanup. Update RestoreLocalBackupFragment.handleBackupImportError to handle the new result using the existing passphrase message and to display the existing RestoreLocalBackupActivity__backup_restore_failed string for FAILURE_UNKNOWN, with an accurate accompanying log message. Leave downgrade and foreign-key handling intact; the existing RestoreLocalBackupViewModel passes through the enum and requires no modification, and all enum references were inspected for exhaustive consumers.

Users restoring local backups receive “Incorrect backup passphrase” even with a verified key, sometimes after thousands of messages have already been read. The full thread includes confirmed incomplete/corrupted file transfers and Signal contributors explaining that unrelated restore exceptions are probably being mislabeled. The current legacy restore repository returns FAILURE_UNKNOWN both when passphrase validation returns false and when an IOException occurs; its fragment labels every such result as an incorrect passphrase. This plan fixes that concrete error-reporting defect, without promising recovery of damaged data or resolution of every historical restore failure collected in this thread.

Fixes #12743

[greyson-signal]

Hi there, this PR edits files that are no longer in use. Registration was rewritten a couple months ago, and this code hasn't been used since then. I should probably go clean it up now that the new version has stabilized. I don't think the new version has this bug.