Fix preference loss when backup archives share a restore store

[AsafMah]

Problem

Restore treats preferences.json and protected_preferences.json as different stores and clears selected categories before applying each. With a device-protected default context (or before Android N), prefs() and protectedPrefs() address the same store. A backup containing current main settings or text-expander entries and an empty or stale protected-preference snapshot can therefore lose restored data when the second snapshot clears that store.

Fix

Collect both entries before applying them. Restore a shared store once, with main preferences taking precedence over legacy protected values regardless of ZIP order. Preserve separate-store behavior and selected-category filtering. Stage removals and puts in one editor, and check parsing and commit results so malformed preferences fail without first clearing existing values.

No archive-format, setting-category, UI, dependency, or unrelated feature changes.

Reproduction and verification

The regression uses real device-protected SharedPreferences and text-expander data, then restores main and empty protected snapshots. Removing alias handling makes the restored shortcuts disappear.

• 11 new Robolectric tests and 2 settings control tests passed, covering API 23, separate and shared stores, category filtering, missing and empty archives, all primitive preference types, and malformed data.
• This fix and a separate fix also passed 89 combined downstream tests. A normal native debug build of downstream v2 succeeded, and the user confirmed it works. Downstream integration build is downstream evidence, not a pure-upstream test run.
• Local JVM verification used an external JNI-disabled, build-tools-36 init script and standard RunTests; production build configuration is unchanged.

The original reporter's exact archive was not inspected. This confirms a data-loss mechanism, not that all text-expander backups fail.