test(fcm): Maestro flow proving FCM cold-wake delivers a sync

[pvg13]

Summary

End-to-end test for the headline contract of `examples/dioxus_fcm_sync`: when the Android app is killed (swiped from recents), a write made by another peer reaches the killed phone via FCM wake-up. Verified empirically — see "Test result" below.

A pass means:

1. The relay correctly maps `NotifyTopic` → FCM token list → `messaging.send()`.
2. The Android app's `FirebaseMessagingService` survives the kill and is invoked when FCM arrives.
3. The Rust engine's background-sync entry point reconnects to the relay, runs version-vector catch-up, and writes the row to local SQLite — all while the UI is dead.

Test result (Google Play Services emulator, AMD x86_64, Linux 6.19)

```
==> Maestro phase A (launch + sentinel + killApp)
phone sentinel: from-phone-1778192513-2978327
==> Waiting for writer to see the sentinel 'from-phone-1778192513-2978327'...
sentinel reached writer after 1s
==> Writer adds task 'from-cli-1778192513-2978327' while phone is killed
==> Sleeping 90s for FCM to deliver and wake the engine in background...
==> Maestro phase B (relaunch + assert)
Assert that "from-cli-1778192513-2978327" is visible... COMPLETED
Assert that "from-phone-1778192513-2978327" is visible... COMPLETED

============================================================
PASS — FCM cold-wake delivered 'from-cli-1778192513-2978327'
to the killed app while the UI was dead.

```

The writer-peer's row landed in the app's local SQLite at first paint of phase B's relaunch — proving the engine was woken in background by FCM, sync ran with the UI dead, and the row was committed before the user re-opened the app.

Why `killApp` and not `am force-stop`

`killApp` (Maestro) is the realistic shape of "user swiped from recents": process exits, FCM still deliverable. `am force-stop` puts the package in stopped state, which Android uses as a security flag to disable FCM until the user manually relaunches — exactly the wrong shape for testing this feature. `TESTING.md` spells this out so future contributors don't 'fix' a flake by switching to `force-stop` and silently invalidating the test.

Files

File	Purpose
`test.maestro.phase-a.yaml`	Setup: launchApp clear, type the per-run sentinel, killApp
`test.maestro.phase-b.yaml`	Assertion: launchApp without clear, assert remote row visible at first paint (5s window) + sentinel still present
`test.sh`	Orchestrator (relay + writer-peer + APK install + maestro phases)
`TESTING.md`	Prerequisites, run instructions, pass/fail interpretation

Sequence

1. Boot a local `wavesync_relay` configured with `FCM_CREDENTIALS`.
2. Boot a writer-peer (the existing `tests-e2e/test-peer` binary, HTTP API, joined to the same relay+topic+passphrase).
3. Build & install the APK via `dx` with `WAVESYNC_RELAY_OVERRIDE` pointing at the local relay (10.0.2.2 for emulator, LAN IP for physical device).
4. Phase A: launch app (clear), add UUID-suffixed sentinel, killApp.
5. Verify the writer-peer received the sentinel — the app→relay path is alive before we proceed.
6. Writer-peer adds a uniquely-titled row while the phone is killed.
7. Sleep 90s for FCM delivery + background sync.
8. Phase B: launchApp (no clear), assert the writer's row + the phone's sentinel are both in the local DB at first paint.

Two small support changes to keep the example pristine for non-test users

• `src/main.rs` reads `WAVESYNC_RELAY_OVERRIDE` via `option_env!()` with the production relay as fallback. Test infra sets it; users building normally see no change.
• `build.rs` adds `cargo:rerun-if-env-changed=WAVESYNC_RELAY_OVERRIDE` so flipping it triggers a rebuild.

Issues fixed during validation

The first run failed and revealed a series of harness bugs. Each commit on the branch documents the fix; the second commit's message has the full list. Highlights:

1. Relay CLI takes one `--listen-addr` (TCP) and advertises additional protocols via `--external-address` — not multiple `--listen-addr` flags.
2. Relay's PeerId is derived from the keypair at runtime — read from the relay's startup log instead of hardcoding.
3. `cargo run --release` cold compile is 5+ minutes; pre-build before starting the test sequence.
4. Android emulators NAT to host as `10.0.2.2`, not LAN IP. Detect emulator and use the right address in `WAVESYNC_RELAY_OVERRIDE`.
5. App's h1 is "WaveSyncDB Mobile Demo", not "Tasks".
6. App generates a UUID for `id` on Add — sentinel lookup must be by title, not by id.
7. Per-run UUID-suffixed sentinels via Maestro `--env` so residual state can't make assertions trivially pass.
8. dx's APK output path is under `${CARGO_TARGET_DIR}/dx/.../release/android/app/...` — find updated.

Test plan

• `cargo check -p example-dioxus-fcm-sync` passes.
• `bash -n test.sh` passes (script syntax OK).
• `./test.sh` end-to-end PASS on a Play-Store emulator (Medium_Phone_API_36.1) with the bundled `google-services.json` and the matching Firebase Admin SDK JSON.