ios: move to the LiveKitWebRTC pod (144.7559.15)

[hiroshihorie]

Stacked on #102. Switches iOS from the WebRTC-SDK pod to LiveKitWebRTC 144.7559.15, the renamed framework with LK-prefixed Objective-C symbols. Also bumps Android to the matching android-prefixed:144.7559.15.

• Imports move from <WebRTC/...> to <LiveKitWebRTC/...> (header names are unchanged).
• Framework types, enums, functions and kRTC... constants are renamed to their LKRTC form. Module-owned names such as RTCVideoViewManager and RTCVideoView, and the JS API, are unchanged.
• LiveKitWebRTC 144.7559.15 is now published on the CocoaPods trunk, so consumers do not need any extra source lines in their Podfile. The livekit/podspecs repository serves the same podspecs and stays documented as an optional additional source for versions that have not reached the trunk CDN yet. On Android, android-prefixed resolves from Maven Central as usual.

Mic permission handling for the manual recording APIs

Starting with 144.7559.12 (webrtc-sdk/webrtc#265) the audio engine no longer requests microphone permission when input is enabled. It only passively checks authorization and fails with -9000, leaving the request to the SDK. getUserMedia already requests and awaits permission, so the standard capture path is unaffected, but the manual AudioDeviceModule recording APIs called the engine directly and would fail with a generic recording_error and no prompt. Since this PR is what moves us past that boundary, it also hardens those APIs:

• AudioDeviceModule.startRecording() and startLocalRecording() now request and await microphone permission first, through the same Permissions module getUserMedia uses, and reject when it is denied.
• The native bridge maps the -9000 result to a dedicated microphone_permission_denied error code, for recording starts and for setEngineAvailability, whose input re-enable path runs the same passive check.
• setEngineAvailability intentionally does not request permission, since it can run in the background where no prompt is possible. The API docs now state that permission must be granted before restoring input availability.

Apps that already had permission (anything using getUserMedia) see no new prompt, the request resolves immediately with the existing grant.

Verification

The library pod target builds for iOS Simulator with Xcode 26.6, with LiveKitWebRTC resolved from the podspecs source. Android module compiles against 144.7559.15. macOS not build-verified (the macOS example is too old to build); the only macOS-specific change is RTCMTLNSVideoView -> LKRTCMTLNSVideoView, which matches the framework headers. For the permission changes, eslint and tsc --noEmit pass, and the permission bridge (WebRTCModule+Permissions.m) compiles on all Apple platforms per the podspec's shared source list.

Trunk publish verified end to end: the LiveKitWebRTC.xcframework.zip served by the podspec has sha256 2edf0cd19759...5821, identical across the webrtc-sdk/webrtc-build m144.7559.15 release asset, the livekit/webrtc-xcframework 144.7559.15 release asset, the SPM checksum in Package.swift, and a fresh local download.