cameraReceiving

Per-role inbound media liveness, sampled from this peer's inbound RTP on the media-liveness cadence. cameraReceiving is true while the peer's CAMERA video bytes are advancing; contentReceiving is true while its CONTENT (screen share) video bytes are advancing. Each is only meaningful when that role's track is expected/active: derive a content stall as content?.active == true && !contentReceiving (and the camera analog from cameraEnabled). The SDK exposes the liveness primitive, not a pre-computed "stalled" flag, so consumers compose it with the expected state and read the peer identity from cid.

Flag off / legacy peers: the single inbound video routes to the camera role, so cameraReceiving tracks that one video and contentReceiving stays false. Both default to false before the first liveness sample. Audio liveness is not split here (it stays in the global media_liveness signal). Additive: existing fields are unchanged.