feat(ios): opt in to successful scheduled-task run notifications #204

Current status (2026-10-16)

Completed within this ticket's written implementation and automated-test boundary. Checked criteria below refer to that boundary, not full physical-device acceptance. Server/native tests cover default silence, success opt-in, queued opt-out/role changes, final aggregation, ownership and exact-run navigation.

Evidence: implementation merged in #206; acceptance checkpoint merged in #218. Candidate Server CI passed 90 mobile-push integration and 95 mobile-router tests. iOS CI passed 473 tests, zero skipped, including all three actual Rust ciphertext consumers. The unchanged Worker has 73 workerd plus one native ingress test; unchanged bilingual guidance has passing documentation CI. Local zh-Hans verification passed 64/64 and all six native redirect-boundary checks passed. Earlier-SHA Worker/docs results are reused evidence, not a fresh candidate-wide run.

The dedicated ServerBee Worker is deployed. One authorized real APNs sandbox test reached a dedicated Simulator: registration revision 2, persisted Server receipt accepted/Accepted, NSE-decrypted background presentation, and opening the existing notification from a terminated app into Settings. No simctl push injection was used. The system required side-swipe to open; earlier failed harness attempts remain recorded. Initial enqueue and raw APNs HTTP responses were not separately captured; the Server receipt reports the Relay/APNs verdict and still correctly says presentation=unobserved. The dedicated session was revoked and confirmed absent. This is not physical-device or production evidence.

Remaining live acceptance is retained in #205 and #196: Actual success subscription, default/opt-out silence and task-run navigation. Closing this implementation ticket does not close or waive those gates.

Dated checkpoints below are historical. This status supersedes earlier statements that the Worker is undeployed or that all live APNs checks are unrun; production and physical-device gates remain pending.

Parent

#196

What to build

An eligible task owner can opt in to successful-run notifications in iOS. Fully successful runs then produce one final encrypted summary, while successful runs remain silent by default.

Acceptance criteria

• Add a Server-confirmed task-success option, disabled by default and visible only for eligible task recipients; failed preference saves remain visible.
• Reuse the established final-run aggregation and owner-selection path; successful-run preference cannot broaden task access or notify unrelated administrators.
• Only a complete run with all target outcomes successful emits a success summary; failures continue through the failure policy without a duplicate success notification.
• Revalidate the preference and role before queued dispatch, so opting out or losing access cancels pending eligible success delivery.
• Use the same encrypted run-target payload and authenticated navigation; no commands or outputs enter push content.
• Verify default silence, opt-in, opt-out while queued, failure followed by a successful retry, mixed-target failure, recipient ownership, and one-summary behavior through the existing Server/iOS seams.

Blocked by

• feat(ios): notify task owners of final run failures #203: feat(ios): notify task owners of final run failures