[MitsuhaMone]

Summary

The per-backup note (introduced with #1037) is the most specific piece of information a user can attach to a backup — but it is currently not searchable. This PR makes the existing search feature cover it end to end:

1. App list search now also matches the note of any backup of a package.
2. App page: while a search is active, the backups list is filtered down to the backups whose note matches — dozens of unrelated backups are hidden away.
3. Restore page (batch restore with singularBackupRestore): each app's backup list is filtered the same way, so the matching backup can be checked and restored directly.

Use case

Many users keep a long history of backups for the same app (scheduled + manual), which are hard to tell apart by timestamp alone. Notes like work account, before factory reset or stable 2.3.1 are the natural way to identify what a backup contains — the original request in #1037 was exactly about identifying which account a backup belongs to.

Right now, finding a specific backup means opening each app and scanning through its long backups list manually. With this PR:

• type factory reset in the search bar → only apps that have a backup noted "before factory reset" remain in the list
• open one of them → only the backups whose note matches are shown, instead of all of them
• switch to the Restore tab (same query still active) → the same filtered backup list is directly checkable for restore

Implementation

• FilterUtils.applySearch(): additionally matches Backup.note of any backup of the package (case-insensitive contains, consistent with the existing matching of label / package name / app-level note / tags).
• FilterUtils.applyNoteSearch(): new helper that filters a backup list by note match, falling back to the full list when no note matches — e.g. when the app was found by its name, its backups list must not suddenly appear empty.
• AppPage accepts the active searchQuery (passed from HomePage, so it stays live while the search bar is expanded) and filters backupsNewestFirst with it.
• RestorePackageItem filters the per-app backup list by the same rule, preserving the original backupsNewestFirst indices — those indices address the backup to restore in AppActionWork (pi.backupsNewestFirst[backupIndex]), so a restore always targets exactly the backup the user selected, even when the displayed list is filtered.

Behavior notes

• With no search active, everything behaves exactly as before.
• Matching is case-insensitive substring matching, identical to the existing search behavior for labels and app-level notes.
• The app-level note and tags keep working as before (they are matched too).

Testing

• assembleRelease builds cleanly (also verified via CI on a fork: fork release build)
• Manual scenario: multiple backups with distinct notes → search by a note fragment → app list, app page and restore page each show only the matching backups → restoring a filtered selection restores exactly the selected backup.

A follow-up idea (not part of this PR to keep it minimal): highlighting the matched note text in the backup items.

[machiav3lli]

LLM-generated code won't be accepted.