[Feature] Let the recording notification's clock start from a caller-supplied elapsed time #492

Environment

• expo-audio-studio version: 3.2.1 (same code on main, 4.0.0-beta.0)
• Expo SDK version: 57
• Platform & OS version: Android 14 (emulator), iOS 26 (simulator)

Description

The recording notification shows a duration that the library counts from startRecording(). An app that resumes a recording session — the same session on the server, a new startRecording() on the phone, with time already on its own clock — ends up with two clocks: the app says 02:30, the notification says 00:37.

The library cannot know about that offset, so the app needs a way to hand it over. Proposal:

startRecording({
  showNotification: true,
  notification: {
    title: 'Visit in progress',
    text: 'Recording',
    // Milliseconds already elapsed when this recording starts; the notification's
    // duration counts from here instead of zero. Default 0.
    initialDurationMs: 150_000,
  },
});

On Android the change is two lines: parse the key in NotificationConfig.fromMap and subtract it from recordingStartTime in AudioNotificationsManager.startUpdates, so every existing duration computation — the one-second refresh, the pause bookkeeping — carries the offset for free. The iOS AudioNotificationManager and the Now Playing elapsed time would take the same offset in startUpdates(startTime:).

Things I would like your opinion on before writing the PR:

• Where the key lives: at the notification level (as above), since it concerns the displayed duration only and not the file, or under android / ios per platform.
• Whether it should also shift what getStatus() reports as durationMs, or stay a display-only concern. I lean display-only: the file and the session the library records really do start at zero.
• Naming: initialDurationMs, elapsedMs, startOffsetMs.

Cross-Platform Validation

Reproduces with any app that calls startRecording() more than once for what it presents as one session; the AudioPlayground app has no such flow, so it cannot show it. Verified on Android with a pnpm patch implementing the proposal above: with initialDurationMs: 150_000 the notification starts at 02:30 and stays in step with the app's clock through pause and resume.

Related: the standard-template fix for the blank Android notification (#491), which this would build on.