ci(android): instrumentation smoke suite fails on emulator boot flakiness #154

Context

While verifying three unrelated PRs today (#144, #146, #153 — a deep-link manifest fix, a dead-resource cleanup, and push-notification scaffolding touching completely different files), the `Android instrumentation smoke suite` CI job failed identically on all three, with the same signature every time:

```
WARNING | Failed to process .ini file /home/runner/.android/emu-update-last-check.ini for reading.
WARNING | Failed to load snapshot 'default_boot'
The process '/usr/local/lib/android/sdk/platform-tools/adb' failed with exit code 1
--- com.android.systemui.emulation.pixel_6 ' failed: '/system/bin/sh: com.android.systemui: inaccessible or not found
```

This cascades into ~16/23 instrumentation tests failing with unrelated symptoms (`MainActivityIntentDeliveryTest`, `AccessibilitySemanticsTest`, `InkwellNavHostTest` all fail with things like `Intent in process uk.ewancroft.inkwell.debug resolved to different process uk.ewancroft.inkwell.debug.test` and `Activity never becomes requested state "[DESTROYED]"`) — none of which are plausibly caused by any of the three PRs' actual diffs (one touched only `AndroidManifest.xml`'s `` block, one only deleted unused resource entries, one touched `shared/`, iOS, and website files with zero Android app code changed).

Likely cause

Emulator snapshot/boot instability on the GitHub Actions runner (`Failed to load snapshot 'default_boot'`) cascading into every subsequent `adb`-dependent step. This looks like a CI infrastructure issue — possibly an emulator image/snapshot compatibility problem, insufficient boot wait/retry logic in the workflow, or a resource-constrained runner — not an app code issue.

Suggested next steps

• Check whether the workflow's emulator setup step (`.github/workflows/ci.yml`, `android-instrumentation` job) has retry/wait logic for a cold boot without a snapshot, since "Failed to load snapshot" implies it's falling back to a cold boot that apparently isn't completing reliably.
• Consider whether the emulator image/API level pinned in CI needs updating, or whether `-no-snapshot-load` should be explicit rather than implicitly falling back.
• This was not investigated further since it's clearly a CI infrastructure question, not something to fix blind alongside unrelated feature work.