[dhruva-vapi]

Value

Sites that embed the Vapi voice widget stop creating calls before the visitor has allowed the microphone.

Today the widget creates the call first, and the browser asks for the microphone afterwards. If the visitor is slow to answer the prompt or blocks it, the call sits silent and the server ends it as assistant-did-not-receive-customer-audio. Zeals saw about 40% of their widget calls end this way.

@vapi-ai/web 3.0.1 (VapiAI/client-sdk-web#189) asks for the microphone first and creates no call if the visitor blocks it. The widget's embed script bundles its own copy of the SDK, and that copy was still 2.5.0, so widget users never got the fix. This PR bundles 3.0.1.

Small edit since first push: the widget now ignores the SDK's recoverable errors instead of showing the call as ended, and the peer range accepts 3.0.0.

What changed

• The embed script now bundles @vapi-ai/web 3.0.1. It is a dev dependency so the lockfile pins the version that gets bundled.
• The peer range is now ^2.5.0 || ^3.0.0, so apps that use the React components with their own 2.x SDK are not forced to upgrade.
• The widget no longer treats every SDK error as the end of the call. 3.x reports some recoverable problems as errors while the call keeps running, for example a noise-cancellation setup failure or the assistant's audio being blocked from playing. Before, those flipped the widget back to its Start button while the call and microphone were still live, so the visitor could not end the call. Errors that end or prevent a call, including a blocked microphone, still reset the widget.
• A Playwright test covers the three cases below against the built embed script.

Testing plan

New tests/widget-microphone.spec.ts, run in Chromium with the API stubbed so no real call is placed:

Case	2.5.0 (before)	3.0.1 (this PR)
Microphone blocked	call created, test fails	no call, widget returns to its start button
Prompt not answered yet	call created, test fails	no call while the prompt is open
Microphone allowed	call created	call created

The existing six embed tests, lint, format check, type check, and both builds pass locally on Node 22. CI runs on Node 18, while @vapi-ai/web 3.x and @daily-co/daily-js 0.93 declare Node >=22.14. npm treats that as a warning, but this PR's CI run is the first check of it.