feat: voice-activity streaming mode & inner-vad for speech-to-text module

[IgorSwat]

Description

This PR introduces changes focused on voice-activity-detection module and it's utilization within the library:

• Native side VAD streaming - introduces a continuous voice-activity-detection mechanism with user-friendly callback system. Example usage from demo app:

  await model.stream({
    onSpeechBegin: () => {...},
    onSpeechEnd: () => {...},
    options: {...},
  });

• VAD x STT integration - adds an option to utilize voice-activity-detection within the speech-to-text module, significantly improving the effective performance of the STT.
• Demo apps: introduces new screen in the speech demo app: VoiceActivityDetectionScreen and changes the behavior of SpeechToTextScreen, adding a toggle to switch the VAD submodule for STT on/off.

Introduces a breaking change?

• Yes
• No

Type of change

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Documentation update (improves or adds clarity to existing documentation)
• Other (chores, tests, code style improvements etc.)

Tested on

• iOS
• Android

Testing instructions

• To test the VAD streaming: run the VoiceActivityDetectionScreen within the Speech demo app.
• To test the VAD & STT integration: run the SpeechToTextScreen within the Speech demo app, with VAD toggle on.

Screenshots

Related issues

#1118

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

Additional notes

[msluszniak]

Please also fix these warnings:

[msluszniak]

stream() resolves as soon as this.isStreaming flips, but the native loop only re-checks the flag at the top of the next iteration — so for up to timeout + one inference after await streamStop() returns, the native streamer is still alive, can still queue callInvoker_->invokeAsync callbacks, and still touches audioBuffer_. If the caller then runs unload() (or the host object is destroyed) we're in UAF / use-after-unload territory.

Two options: (a) actually join — stream() doesn't resolve until the native stream() call returns, and streamStop() awaits that; or (b) document explicitly that unload() is not safe immediately after streamStop() and that callbacks may fire after the promise resolves. (a) is the safer contract.

[msluszniak]

Both streamInsert and streamStop go through runForward, which gates on isGenerating. While stream() is running, isGenerating is true, so every streamInsert(buffer) call rejects with "model is currently generating" — which is what Jakub hit on the rapid-tap repro. That thread is marked resolved, but I don't see the fix in either useVAD.ts or VADModule.ts. At minimum streamInsert (a buffer push) must bypass runForward for the streaming API to function; arguably streamStop should bypass too — you may want to stop precisely because inference is stuck.

[IgorSwat]

If it's true, then that's a Module Factory issue - and I don't think this PR is a good place to fix it.

[chmjkb]

besides my previous comment, I think it looks good, great work!