test(ios): scheduled notification can fire before simulator app termination

Evidence

The Android-only minimum-SDK PR #301 failed its unrelated iOS shim notification test in run 35892860064, job 107289368002. The runtime leg passed all 12 cases; cold push and foreground receipt reports passed on the shim leg.

The uploaded XCUITest log shows:

• t=44.06: open the local scheduling link.
• t=64.62: begin waiting for CRAFT-E2E-LOCAL-SCHEDULED.
• t=80.08: observe the scheduling success label.
• t=80.12: request app termination.
• t=112.15: app reaches notRunning.
• The subsequent 120-second banner wait finds no local banner.

The driver schedules that notification with delay: 8000. Termination alone took about 32 seconds, so the notification can fire before the test reaches its cold-start banner tap. This is strong evidence of a harness timing race, not proof of an Android regression. One failed-job retry is in progress; the original failure remains relevant even if it passes.

Expected follow-up

Make the local notification cold-start phase robust to simulator scheduling/termination latency while still asserting that the app is stopped before the tap. Keep bounded timeouts, inspectable evidence, and both shim/runtime coverage. Do not treat repeated retries or silently skipping the local phase as a fix.

The single failed-job retry of run 35892860064 completed successfully. This supports the timing-flake diagnosis, but does not fix the eight-second scheduling window or invalidate the original simulator evidence. Keeping this issue open for a deterministic harness fix.