fix(mobile): accept the confirmation-time notification re-render, and let an unresolved start be cleared

[krishagel]

What broke

A drill started from the phone at 18:54 PDT on 2026-09-15 reached the server, created the event, and sent three push notifications. The app then refused the response, reported that it could not determine the outcome, and left the device unable to start or join anything afterwards.

Server evidence: start-event "outcome":"success" at 2026-09-16T01:54:05.930Z, request e11a614b, followed by push-worker-message-completed count 3. No server error. The failure was entirely on the client's side of a successful exchange.

Root cause

buildNotification re-renders notification copy at confirmation on purpose — the sent message carries the real start time, the confirming person, and current school and response names rather than the preview's guesses. The source says so at events.ts:512, then replaces renderedMessage on every channel of the intent.

activationMatchesPreview compared the intent's channels to the preview's with structurallyEqual — byte-for-byte deep equality. The preview renders with its own createdAt (start-preview.ts:214); the activation renders with the real activation time. {{startTime}} formats at minute granularity (START_TIME_FORMATTER, no seconds), so the two agree whenever preview and confirmation fall in the same clock minute and disagree whenever they straddle one. The longer an operator spends on the confirmation screen, the more likely the start is rejected — the opposite of what an emergency tool should do. The same applies to the other values the comment names: the confirming person's name, and school or response names changed inside the preview's fifteen-minute window.

Both the confirmation-time re-render and the {{startTime}} token entered in 34432c58 (2026-09-09), which reached production in the 2026-09-09 deploys. The mechanism is proven and reproduced in test; which of those values differed in this particular run is not individually confirmed, and the fix covers all of them.

Second defect: the unknown outcome was absorbing

Once latched, nothing could clear it. acknowledge accepts only succeeded or failed; every other clearDurableRecordOrBlock path carries the same guard; sign-out clears the session vault but not the start-mutation record, which lives in the keychain and survives restarts. The screen offered only a read-only check.

resolveActivationFromFreshEvents previously promoted an ambiguous activation from the active-event list and was removed — correctly, since that list carries no request-specific idempotency correlation. But removing the inference left no exit, so one ambiguous request disabled every later start and join on the device.

The inference stays removed; the decision returns to the operator via an explicit Clear and allow new decisions control. The copy still makes no claim about whether the earlier request succeeded or failed.

The test that should have caught this

The activation fixture built the intent as channels: preview.channels — comparing the preview to itself. The strictest condition in the client was never exercised. It now models the confirmation re-render, and restoring the old comparison reproduces the original rejection.

Coverage added

• A re-rendered message is accepted.
• A changed classification marker, endpoint count, integration, dropped channel, or reordered channel set is still refused.
• An unresolved fence clears on acknowledgement and admits the next start.
• The clear is refused for another owner and once already idle, and is disabled while offline.

Gate

Prettier, ESLint, and typecheck clean across the repository. 6/6 test shards green; 61 mobile native tests pass. Database-backed suite not run in this worktree.

Platform parity

Client-only logic and shared React Native UI — no platform-specific code. Needs verifying on iOS and Android before release.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[claude]

Review: #512 — accept confirmation-time re-render, allow clearing an unresolved start

Clean diff. No IMPORTANT findings. This is a well-scoped fix with strong test coverage for both defects it addresses.

What I checked

• channelAuthorizationMatches (start-api-client.ts:456-491) replaces byte-for-byte structurallyEqual on intent.channels with a comparison of channel, endpointCount, integrationId, and renderedMessage.classificationMarker per index. Cross-checked against the server's own DispatchBatchSchema (packages/contracts/src/notification.ts:379-462), which treats channel/eventKind/templateMode/purpose/classificationMarker as batch identity and renderedMessage wording as free to vary — the new client check is a faithful subset of that server-side invariant. eventKind, templateMode, purpose, rosterSnapshotId, and rosterPopulation are still asserted at the intent level in activationMatchesPreview (start-api-client.ts:500-523), so per-channel classificationMarker is defense-in-depth, not the only guard. No weakening of what the operator authorized (channel set, order, endpoint count, sending integration, drill-vs-incident marker all still exact-match).
• acknowledgeUnresolved (start-mutation-coordinator.ts:869-896, start-mutation-provider.tsx:315-320) mirrors the existing acknowledge method's owner/online/phase guards exactly, and reuses the already-tested clearDurableRecordOrBlock path rather than introducing new persistence-failure handling. The UI wiring in app/index.tsx:395-400 and app/start/index.tsx:686-692 differs only by an appropriate returnHome() call on the start screen vs. none on the home screen — consistent with each screen's role.
• Type modeling: onAcknowledgeUnresolved is never on Pending/Failed props and required on Unresolved props, so the compiler enforces the control only appears where it's meaningful.
• Tests actually assert behavior: the new start-api-client.test.ts fixture (reRenderedAtConfirmation) now diverges preview vs. confirmation copy, which is the root-cause fix for the original bug — previously channels: preview.channels made the strictest check compare the preview to itself. The added "still refuses" test varies classification marker, endpoint count, integration, dropped channel, and reordered channels independently and asserts outcomeUnknown: true for each. Coordinator tests cover clear-then-resubmit, wrong-owner refusal, and already-idle refusal. The offline-disabled test checks accessibilityState/disabled props only (doesn't simulate a blocked press), but that matches the existing convention for the sibling "Check active events" offline test (start-mutation-attention.test.tsx:318-320) — not a new gap.
• No logging/telemetry changes in this diff and no student PII in scope — this is client-side start/join mutation-state handling only.
• No CI weakening: no tests removed or skipped; one assertion in an existing test was tightened (toHaveLength(1) → explicit label list) to reflect the new control, not loosened.

Nits (0)

None worth raising.