feat(ios): support isLiveStream in PlaybackNotificationInfo

[gavrichards]

What

Adds isLiveStream?: boolean to PlaybackNotificationInfo. On iOS, it's mapped to
MPNowPlayingInfoPropertyIsLiveStream, which drives the system "Live" label shown on the lock screen
and in CarPlay's Now Playing UI for content with no fixed duration (live radio, live events, etc.).
No effect on Android — there's no equivalent system-level indicator there.

Why

For an app playing live radio streams alongside on-demand content, the lock screen currently has no
way to distinguish "live" from "has a real duration" — duration/elapsedTime are the only signals,
and omitting them just means no scrubber, not an actual "Live" indicator. This is a small, additive
change that closes that gap using the same key-mapping mechanism every other PlaybackNotificationInfo
field already uses.

How

showNotification's native module signature already takes a generic, untyped options map
(OptionsMap = { [key: string]: string | boolean | number | undefined } in NativeAudioAPIModule.ts),
so no TurboModule/codegen changes are needed on either platform — this follows the exact same path
title, duration, skipInterval, etc. already use.

• src/system/notification/types.ts — add the isLiveStream?: boolean field.
• ios/.../PlaybackNotification.mm — add @"isLiveStream" : MPNowPlayingInfoPropertyIsLiveStream to
  the existing NOW_PLAYING_INFO_KEYS map. updateNowPlayingInfo:'s update loop already writes any
  key present in that map generically, so this one line is the entire native change.
• packages/audiodocs/docs/system/playback-notification-manager.mdx — documented the new field
  alongside the existing ones.
• Android untouched deliberately — I read through PlaybackNotification.kt's full show/update path
  and found no rendering surface for a "Live" badge in Android's own MediaStyle notification/lock
  screen to map this to; happy to be corrected if there's a convention I'm missing.

Testing

I have not yet verified this on a real device — this is based on reading the source (the
NOW_PLAYING_INFO_KEYS mapping table and the generic update loop), not a device/simulator run against
a real lock screen or CarPlay session. Apple's docs note MPNowPlayingInfoPropertyIsLiveStream can
affect how the system renders duration/elapsed time alongside it, which I haven't been able to confirm
interacts cleanly with duration/elapsedTime still being set. If this looks right in principle, I'd
appreciate help confirming actual on-device behavior before merge, or pointers to an existing
test/example app flow I should run it through.

Notes on process

I know CONTRIBUTING.md asks that new-feature PRs be preceded by a design doc — given the change is
additive and small (one optional field, one native mapping entry, no API changes to anything existing),
I've folded the rationale into this description rather than opening a separate doc first. Happy to open
a discussion/issue instead if that's preferred for something this size.

[github-actions]

WPT non-regression comparison

PASS — no regressions · 1 improved section(s) · overall 2585 → 2589 (+4)

Spec section	Base pass	Head pass	Delta
AudioContext	54	58	+4

Unchanged sections (27)

Spec section	Base pass	Head pass	Delta
Processing model	0	0	0
Other	52	52	0
AnalyserNode	138	138	0
AudioBuffer	140	140	0
AudioBufferSourceNode	208	208	0
AudioNode	261	261	0
AudioParam	599	599	0
BiquadFilterNode	232	232	0
ChannelMergerNode	30	30	0
ChannelSplitterNode	7	7	0
ConstantSourceNode	59	59	0
ConvolverNode	170	170	0
DelayNode	104	104	0
DestinationNode	0	0	0
DynamicsCompressorNode	4	4	0
GainNode	15	15	0
IIRFilterNode	87	87	0
MediaElementAudioSourceNode	0	0	0
MediaStreamAudioDestinationNode	1	1	0
MediaStreamAudioSourceNode	0	0	0
OfflineAudioContext	35	35	0
OscillatorNode	104	104	0
PannerNode	75	75	0
PeriodicWave	33	33	0
ScriptProcessorNode	0	0	0
StereoPannerNode	102	102	0
WaveShaperNode	75	75	0

_{Baseline: 6f579e9de254e0fc7910babdab5bccc82c9d475a · Candidate: 7447c89600ce0185151c9cd06cf186a34994273f}

_{Workflow run · this comment is updated on every push.}