[Sealdot]

Addresses the persistence portion of #3550. Android batch leaves Notification.sourceJson unset, so scheduled entries are currently stored as the literal JSON null. Reading those entries either produces no restorable notification or adds a null object to the pending list.

Persist the current notification model instead, with sourceJson kept as non-serialized metadata. Normalize a private copy of the storage mapper so both plugin and boot readers can restore the same model. Preserve nested extra / attachment options and allowWhileIdle for all schedule kinds. Skip unreadable or null records without deleting their IDs; payloads already lost as null cannot be recovered.

Added nine storage regression cases and an AndroidX instrumentation wrapper using an isolated preferences file. No command, JS API, dependency, or lockfile changes. Includes paired patch changesets.

Prior host validation on macOS arm64 (2026-10-23):

• The same nine test bodies ran in a host JVM with two Jackson configurations (with/without the Tauri JsonOrgModule): baseline 14 failures / 4 passes; candidate 18 passes. They use production Kotlin models/storage and actual Android framework/org.json classes, with in-memory Context/SharedPreferences substitutes.
• Pending-list JSON output preserved nested extra and schedule flags under the Tauri mapper configuration. Changeset, license, Prettier and whitespace checks passed.
• Rust 1.97.1: per-crate default and all-feature Clippy with -D warnings, all-target/all-feature tests (4 passed), doc tests (4 passed), and workspace format check passed. Rust 1.90.0 MSRV check passed. These are macOS Rust checks, not Android build or device tests.

Android acceptance completed on 2026-10-30, using an Android 16 / API 36 Google APIs arm64 emulator and a minimal debug Tauri app linking the exact plugin sources in this PR (Tauri core 2.12.0, CLI 2.12.2):

• Full aarch64 debug APK build through tauri android build --ci --debug --target aarch64 --apk, plus the Android instrumentation APK. App and Android libraries used compileSdk 36; the app targeted API 36.
• Run NotificationStorageInstrumentedTest on Android with real Context/SharedPreferences: the same nine test methods produced 7 failures / 2 passes on the original four Kotlin files and 9 passes on this PR.
• Real WebView-to-native batch / getPending IPC preserved nested extra and schedule flags. The on-disk XML contained the complete payload; a new app process read it back alongside injected historical null, malformed JSON and non-string entries, retaining their keys.
• An adb reboot without manually opening the app restored the system alarm. A subsequent cold boot of the same installed APK and persisted payload confirmed actual notification delivery (id 355002), system start of LocalNotificationRestoreReceiver, one-shot record deletion, and retention of the legacy keys. The payload was overdue by that cold boot, also exercising the existing overdue-date rescheduling path.

Validation ran in serial stages on a memory-constrained host. A host resource interruption separated the successful reboot-alarm check from the final cold-boot delivery observation of the same persisted payload. No synthetic boot broadcast or manual notification posting was used. Physical devices/OEM behavior, other Android API levels and release builds remain untested. Upstream workflows still await maintainer approval.

This does not address the issue's exact-to-inexact fallback or the separate sendNotification(schedule) path. The old cancelAll missing-argument problem is independent and is already handled by the current default branch. #3296 touches related storage/action files but still writes sourceJson; its cold-start queue changes are outside this patch.

AI assistance: implementation, tests and this PR description were prepared with OpenAI Codex. The submitting contributor remains responsible for reviewing and testing the changes under the repository policy.

[RubyBit]

Let me know when you ready this for review, I have a dependent pr