test(mobile): pin the iOS Live Activity card count and Approve path

[iscekic]

Changelog for users

No user-visible change.

Changelog for maintainers

• Adds a unit test that carries one waiting permission from the session row through the glanceable snapshot, the Live Activity content state, the widget interaction event, and the real front-approval service, then asserts the republished count falls to zero.
• The test delivers the native event as the widget process sends it: the source is the per-activity UUID, so the approve handler matches the target string alone.
• Adds a layout-source test that pins the watch card's ranked count row ahead of the Approve gate, so a wait with nothing approvable still reads its count on the wrist.
• The widget layout never runs under vitest, so both card tests read layout source text; an edit to the watch section is a contract change, not an internal refactor.

E2E proof — log excerpts

iOS verification passed. --- shard 1 ---

Owner request

Surface: the mobile app (apps/mobile).

Prove PR 6199 live on iOS, on a Mac simulator. The PR's whole proof section is one self-declared line ("-> pass :: owner-manual: the Apple Watch Live Activity card count, the wrist Approve tap ...") and nothing ran on the Mac.

Prove what the simulator can show, and capture it:

• the iPhone side: the Live Activity card for a waiting agent, its count, and the approve path the app exposes;
• the paired Apple Watch simulator: the watch app launched with the Live Activity card visible, captured with xcrun simctl io <watch-udid> screenshot.

A wrist tap that the simulator cannot deliver stays an owner-manual scope and must be reported as owner_manual, never as a pass.

Owner manual verification

Owner verification is pending; these checks did not pass automatically.

• Apple Watch wrist tap: tapping Approve on the watch wrist itself (the simulator cannot deliver the wrist tap).

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

Executive Summary

Test-only PR (2 files, 217 added lines) pinning the iOS Live Activity wait/approve chain and the watch card row ordering; the assertions match the current source, snapshot, and front-approval contracts, and no correctness, security, or leak concerns were found.

Verified against HEAD 2e105c48: buildGlanceableSnapshot yields needsInput/needsApproval of 1 for a permission row and 0 for the post-approval busy row; handleApproveInteraction matches on target alone, so the injected native source of an activity UUID is faithful; and countRow(primary, true, false) sits ahead of the {needsApproval ? ( gate inside bannerSmall in active-agents-live-activity.tsx.

Files Reviewed (2 files)

• apps/mobile/src/glanceable-ios/approve-flow.test.ts
• apps/mobile/src/glanceable-ios/layout-copy.test.ts

---

_{Reviewed by deepseek-v4.1-flash · Input: 0 · Output: 0 · Cached: 0}

_{Review guidance: REVIEW.md from base branch kwf/approve-from-the-watch-cfaa}

[iscekic]

(bot) kwf reopened its section for this PR: verification restarted (phase verify) The proof in the body came from an earlier round and can be stale. This PR is human-ready, so nothing here was changed.