feat(mobile): return typed handles from Live Activities APIs

Problem

Craft currently exposes two incompatible Live Activities shapes:

• craft-native/mobile starts an activity from an activityId, then updates and ends an implicit singleton.
• api/ios-advanced returns an id from start, then requires that id for update and end.

The browser-safe API cannot express which activity a call targets, so it cannot safely support more than one activity or protect a recording from updating or ending another live activity.

Proposed API

Make the browser-safe mobile API use the same handle or id model as the iOS advanced API:

interface LiveActivityHandle {
  id: string
  update(state: LiveActivityState): Promise<void>
  end(finalState?: LiveActivityState): Promise<void>
}

interface LiveActivitiesApi {
  start(options: LiveActivityOptions): Promise<LiveActivityHandle>
  update(id: string, state: LiveActivityState): Promise<void>
  end(id: string, finalState?: LiveActivityState): Promise<void>
}

The current singleton calls could remain as deprecated compatibility helpers for one release.

Why this matters

WildLoop uses Live Activities for an in-progress trail recording. A typed activity handle lets a resumed recording update only its own lock-screen activity and makes restoration after a background transition unambiguous.

Acceptance criteria

• The browser-safe and iOS advanced APIs use one consistent activity identity model.
• More than one live activity can be started, updated, and ended without cross-talk.
• The public TypeScript declarations and bridge tests cover the handle or id lifecycle.
• Existing singleton callers have a documented migration path.

Implemented and shipped on main in 07f2342 (feat(mobile): return typed Live Activity handles). The mobile Live Activities APIs now return typed handles, with regression coverage included; the commit's CI, SBOM, Binary Size, and Benchmark workflows passed.