feat(android): promote running sessions to an ongoing notification

[RonenMars]

Stacked on #422. Final PR of the five — Phase 1b (APNs + renewal) is out of scope.

Surfaces a running session on Android as an ongoing notification, resolved through Metro's platform extension so the call site in _layout stays platform-agnostic.
decideActions is reused unchanged, so the cap of three and least-recently-updated eviction behave identically to iOS.

This is not the promoted status-bar chip, and cannot be yet

The plan targeted Android 16's promoted ongoing notification via setRequestPromotedOngoing + setUsesChronometer.
expo-notifications exposes neither. It offers sticky, which maps to setOngoing, and that is the whole surface — there is no chip to request and no chronometer to drive.

So this lands as the plain ongoing notification the runbook names as the acceptable v1 floor.
Elapsed time is omitted rather than rendered: without a chronometer it could only be a snapshot that silently goes stale, and a wrong timer is worse than no timer.

Closing the gap needs those two builder calls exposed upstream or a small native module.
Recorded in docs/expo-web-support.md rather than papered over.

POST_PROMOTED_NOTIFICATIONS is deliberately not declared — nothing can request promotion, and an unused permission is just noise in the manifest.
POST_NOTIFICATIONS is added, since it was previously declared nowhere.

Implementation notes

Posting with an existing identifier replaces the notification in place, so start and update are the same call and an update cannot stack a duplicate.

Notifications are tagged liveSession: true in their data payload.
Adoption after a restart has to clear our own stale surfaces without dismissing push notifications, which also carry a sessionId — filtering on that alone would have cleared the wrong things.

The channel is created at IMPORTANCE_DEFAULT; anything lower forfeits promotion on API 36+ and can be collapsed out of the shade entirely.

The Platform.OS === 'ios' guards in the iOS module are dropped: with .android.ts and .web.ts siblings present, that file is only ever the iOS resolution and the checks were dead code.

Verification

6 new unit tests: payload shape, waiting_input vs running, in-place replacement, terminal dismissal, shared cap eviction, and that adoption spares push notifications.
npm run test:unit 930/930 green; lint 0 errors; typecheck unchanged from baseline.

Device verification on Android 13–15 and 16+ hardware is still pending, including the aggressive-battery OEM check.

---

CI is red on this branch, and it was red before this work

Type check, i18n, and Integration tests fail here. None of those failures come from this stack.

Measured on a clean worktree at integration-merge-354-355-376 (f2242bc4) with no changes applied:

• Type check — 3 errors: makeSearchStyles in app/conversation/[id].tsx:67, plus two i18n key-signature errors in components/onboarding/steps/ConnectStep.tsx:196,197.
• i18n — 3 failures in 1 suite.
• Integration tests — 4 suites / 34 tests, all __tests__/integration/conversation-*.

CI on this branch reports the identical Test Suites: 4 failed, 36 passed / Tests: 34 failed, 211 passed, and tsc reports the same 3 errors and no others.
Independently confirmed by the repo owner against their own clean worktree.

These are deliberately left alone — fixing them is unrelated to Live Activities and belongs in its own PR.