fix: isolate activity backup restore slices

[jvsena42]

Fixes #1167

This PR applies the three Core-owned slices of an activity backup independently on restore, so one rejected record can no longer discard the others.

Follow-up to #1163, and the app half of synonymdev/bitkit-core#134.

Description

The activity restore upserted activities, tags and closed channels inside a single runCatching. Core fails a bulk write as a whole, so the first slice to throw aborted the calls after it. A single tag whose parent activity was missing therefore cost the activities and the closed channels too, and an entire restored category was lost from one bad record. This was reproduced on regtest while building #1163, where activity_tags went from one row to zero and closed channels were skipped entirely:

Failed to restore activity backup [errorDetails=Failed to insert tag: FOREIGN KEY constraint failed]

#1163 removed the hardware wallet trigger by carrying those tags as pre-activity metadata, so this is no longer easy to hit, but it is not impossible. The backup envelope is assembled from three separate Core reads rather than one snapshot, so a tag written against a brand-new activity between the first and the third read lands in the envelope without its parent, in the default wallet scope, with no hardware wallet involved. The window is narrow, the blast radius is not.

Each slice now runs in its own runSuspendCatching, and every failure is logged with the slice it came from. The overall result is still a failure when any slice failed, which matters because the VSS rewrite is gated on the restore succeeding: a partial restore must not be treated as authoritative, or it would overwrite a good backup with incomplete state.

Two smaller changes come with it. Slices that did apply now notify observers even when a later slice failed, so restored activities reach the UI instead of waiting for the next sync. And moving from runCatching to runSuspendCatching means a cancelled restore propagates instead of being swallowed as a failed slice.

Core keeping the valid records within a single bulk write is tracked separately in synonymdev/bitkit-core#134. The two are complementary: Core limits the loss to the bad record, this limits the loss to the affected slice. Neither depends on the other.

Preview

N/A

QA Notes

Reaching the failing-slice path by hand needs a tag whose parent activity is missing from the envelope, which #1163 made hard to produce, so the isolation contract is covered by unit tests instead and manual QA is a restore regression pass.

Manual Tests

• 1. regression: Wallet with tagged activity and a closed channel → wipe wallet → restore from seed → Home: activities and their tags are present.
  • 1b. regression: Settings → Lightning Connections → Closed: the closed channel is present.
• 2. regression: Restore the same wallet a second time → Settings → Data Backups: Transaction Log is not re-uploaded.

Automated Checks

• Unit tests added: cover slice isolation in ActivityRepoTest.kt. One case per failing slice asserts the other two were still applied and that the overall result is a failure, alongside an all-slices-succeed case and a cancellation case pinning the runSuspendCatching switch.
• Existing coverage in BackupRepoTest.kt is unchanged and still green, including activity backup is not rewritten when core restore fails, which pins the VSS rewrite gate this PR depends on.
• Local just compile, just test file ActivityRepoTest, just test file BackupRepoTest and just lint pass.