fix: report the waiting room for web bots

[rafaeljusto]

BotStates.WAITING_ROOM and BOT_PUT_IN_WAITING_ROOM already exist and bot_controller already turns the message into a state change, but only the Zoom Native SDK adapter ever sends it — the web adapters just poll for the meeting UI. An API consumer therefore cannot tell a bot held in the lobby from one still connecting, and only learns about it when the waiting room times out.

Detect the lobby inside the Zoom Web SDK, Teams and Google Meet post-join poll loops and send the message once. The bot_controller handler now checks the bot is still JOINING, since joining -> waiting_room is a one-shot transition and create_event raises on any other source state.

To preserve existing API behavior this new behavior is gated behind a boolean env var ENABLE_WAITING_ROOM_STATE_FOR_WEB_BOTS

[rafaeljusto]

The patch fixes one specific blind spot: Attendee.dev never tells us a bot is waiting in the lobby, so we can only ever report the failure after it's too late to do anything about it.

Concretely, today's signal timeline for a Teams meeting is:

time	what Attendee tells us
T+0	joining
T+0…T+10min	nothing — bot is in the lobby, state still joining
T+10min	could_not_join_meeting / waiting_room_timeout_exceeded

From our side, a bot held in the lobby is indistinguishable from a bot still starting Chrome. The state machine has WAITING_ROOM, bot_controller does turn a BOT_PUT_IN_WAITING_ROOM message into a state change and a bot.state_change webhook — but only zoom_bot_adapter ever sends that message. The Teams and Meet adapters know perfectly well they're in the lobby (their own poll loops check for "Someone will let you in soon" / "Asking to be let in") and just never say so.

So the patch is about converting a 10-minute silence into an actionable event.

[noah-duncan]

Thanks @rafaeljusto ! We should support this. Will review and add some small changes soon, there a few minor things I'd do differently.

[noah-duncan]

Thanks @rafaeljusto !