fix: keep device-captured audio out of sink-fed audio senders

[devopvoid]

Fixes #217, fixes #118, fixes #213

The crash

WebRTC's AudioState starts the factory's AudioDeviceModule recording as soon as any audio send stream starts, and AudioTransportImpl fans every captured frame out to every send stream of that factory. A send stream whose track is backed by a CustomAudioSource already receives its audio through WebRTC's LocalAudioSinkAdapter on the thread that calls pushAudio(). Both feeders enter AudioSendStream::SendAudioData, and its RTC_CHECK_RUNS_SERIALIZED aborts the process:

Fatal error in: ../../audio/audio_send_stream.cc
Check failed: !race_checker.RaceDetected()

That is why single-threading pushAudio() never helped: the second feeder is WebRTC's own capture thread. Where it does not abort, microphone frames are interleaved with the pushed audio instead. Hosts without a microphone never crash, because InitRecording fails, which is why reproduction looked inconsistent. The sinks_ mutex from #285 could not address this; it protects a different list on a different path.

The fix

• ProxyAudioDeviceModule wraps whatever module the factory is created with and gates its capture path. The gate starts closed: InitRecording() and StartRecording() fail so AudioState never opens the device, and recorded frames that still arrive are dropped before they reach WebRTC. Playout is untouched, so received audio still reaches the speakers and AudioTrack sinks.
• One kind of audio input per factory. createAudioSource(AudioOptions) opens the gate and commits the factory to device-captured audio. createAudioTrack with a CustomAudioSource, or adding a sink-fed track (custom or forwarded remote) as a sender, commits it to pushed audio. The other kind is then rejected with an IllegalStateException that names the conflict. Applications needing both create a second factory. RTCRtpSender.replaceTrack and RTCRtpTransceiver.setDirection are not covered by the guard.
• HeadlessAudioDeviceModule loses its capture thread, which pulled the render mix back and handed it to WebRTC as captured audio: an echo to the remote peer and a second feeder on the same send stream. Recording is now a state the module reports and nothing more. This exposed a second bug: the module handed its transport to AudioDeviceBuffer, which refuses it once playout has started, so in the documented ordering received audio never reached a sink. The render thread now pulls the transport directly, without holding the module's state lock across the pull, and the buffer is removed.
• pushAudio() validates its arguments. It accepted any sample width although WebRTC reads 16-bit, read past the end of an array shorter than the claimed frame count, and passed on chunks too large for WebRTC's audio frame, which also aborts the process.

Docs

The custom audio source, headless audio and audio devices guides are updated: the one-input-kind-per-factory rule, 16-bit 10 ms frames from a single thread, the kDummyAudio limitations, and a note that pushed audio bypasses the audio processing module.

Testing

mvn verify is green at 158 tests. New tests cover every conflicting order of the latch, pushAudio validation, and an extended HeadlessADMIntegrationTest that pushes for two seconds while the module's recording is running. The touched test classes also pass under -Pjni-check. The concurrent-feeder abort itself cannot be reproduced in CI without a microphone; on a host with one, WebClientExample crashes before this change and must not afterwards.