feat: Jitsi support

[nabossha]

Adds a Jitsi bot adapter, so Attendee bots can join and record meetings on Jitsi
deployments. Closes #340, where the request was open with no owner and a maintainer
noted there were no technical obstacles and that an outside implementation was welcome.

Bumps version.json from 1.64.1 to 1.65.0 for the minor release.

Recognising a Jitsi URL

Jitsi is domainless: every platform above it in normalize_meeting_url_raw owns a fixed
domain, but a Jitsi room is just https://<any-host>/<room>. Matching on URL shape alone
would swallow unrelated links, so recognition is opt-in through a new
JITSI_MEETING_DOMAINS environment variable, a comma-separated allowlist defaulting to
meet.jit.si. Operators running kMeet, Hostpoint Meet or their own instance add their
hosts to it. The Jitsi branch is checked last, so Zoom, Google Meet and Teams always take
precedence, and the value is read per call rather than at import time so it can be
overridden per environment and per test.

Talking to the app, not the page

Jitsi is heavily whitelabelled — kMeet and Hostpoint Meet restyle the entire interface —
so a DOM-driven adapter would break per deployment. Everything after the prejoin screen
therefore goes through the app itself: join state, lobby knocking and password state are
read from window.APP.store, CONFERENCE_FAILED reasons are recorded off the
lib-jitsi-meet room, and participants, audio tracks and speech events come from
window.APP.conference. The DOM is used for exactly three prejoin controls (app-choice,
name input, join button), matched on data-testid attributes that are identical across
vanilla Jitsi, kMeet and Hostpoint Meet, plus one language-independent icon selector for
kMeet's "join from browser or from the app" screen.

Media is muted through #config.startWithAudioMuted=true&config.startWithVideoMuted=true
in the URL fragment rather than by clicking toggles, so the bot is never briefly live on
camera. Normalised meeting URLs are stored without fragments, so this cannot double up.

Joining as a guest

v1 joins as an anonymous guest only; there is no Jitsi login flow. A room password is
supplied per bot through a new jitsi_settings.room_password, validated by JSON schema
like the other platform settings blocks and documented in docs/openapi.yml. The same
value handles both locked rooms and lobbies, because room.join(password) bypasses an
enabled lobby as well. A missing password on a locked room fails as
could_not_join / room_password; a rejected one fails the same way after a ten second
grace period, which is needed because the passwordRequired state persists briefly after
a correct submission. A wrong password in the lobby case simply leaves the bot knocking,
where a moderator can still admit it. On vanilla Jitsi, where an authenticated moderator
must start the room, the bot surfaces the existing waiting_for_host failure.

Audio only

The payload sends per-participant audio as binary frame type 5, feeding the existing
audio-chunk transcription path, and mixed audio as type 3 when requested. The MP3 itself
is still captured by ffmpeg from the pulseaudio sink monitor, so the payload only taps
tracks and never mutes or reroutes audible playback. Speech start/stop events are derived
from DOMINANT_SPEAKER_CHANGED, which means one speaker at a time — Jitsi does not expose
concurrent per-participant speech state the way the Zoom SDK does. Empty dominant-speaker
ids are handled so a null speaker is never started.

Since Jitsi has no recording-permission concept, the bot moves straight to recording after
joining rather than waiting for a grant.

Two Chrome relaxations

Both are scoped to the bot's own browser, which only ever loads the configured
meeting URL:

• --disable-features=LocalNetworkAccessChecks,PrivateNetworkAccessChecks — recent Chrome
  blocks a public page from opening ws://localhost:<port>, which is exactly the existing
  payload-to-python transport every web adapter relies on.
• Page.setBypassCSP via CDP — kMeet, unlike Google Meet, ships a strict connect-src
  CSP that would otherwise block that same websocket.

Happy to gate either behind the meeting type if you would rather not have them apply
broadly.

Out of scope for this PR

No video recording (send_video is stubbed against a botOutputManager that arrives
later), no captions or transcription from Jitsi itself — Jigasi is not assumed, so
meeting_closed_captions defaults to "no external provider" and captions simply never
arrive — no signed-in or moderator bots, and one dominant speaker rather than concurrent
speech events.

Validation

Tested against three deployments: kMeet by Infomaniak and Hostpoint Meet with live
meetings, and the meet.jit.si API surface. The adapter has been running in production on
a self-hosted Attendee instance recording real kMeet meetings.

• bots/tests/test_meeting_url_utils.py — URL recognition and normalisation, plus
  JITSI_MEETING_DOMAINS override behaviour
• bots/tests/test_jitsi_bot.py — five integration tests tagged jitsi_tests: adapter
  factory dispatch, record-and-auto-leave when all participants leave, bot removed from
  meeting, missing room password, and the silence timeout
• .github/workflows/ci.yml — jitsi_tests added to the teams_and_zoom_web job (now
  teams_zoom_web_and_jitsi) and excluded from others, matching how the other platforms
  are split
• ruff check and ruff format --check clean across the changed files

🤖 Generated with Claude Code

[nabossha]

Pushed one more commit (d093aa5): the bot image now shows up as the bot's camera on Jitsi as well. turnOnWebcam/turnOffWebcam are wired to APP.conference.muteVideo(false/true) — unmuting makes jitsi request getUserMedia({video}), which the existing BotOutputManager interceptor answers with the canvas track, so displayImage() works without any DOM interaction. Verified on kMeet and Hostpoint Meet. Video playback (send_video) remains out of scope as described above.

[noah-duncan]

Hi @nandobosshart thanks for this PR, it looks high quality at first glance. I can't make any guarantees about when we can merge this in as it is a big PR, demand for Jitsi support is almost non-existent among our paying customers and we currently have high demand for other things from our paying customers.

But Jitsi is philosophically in alignment with Attendee so we will try to get this merged in eventually.

Thank for your work!

Edit: Reading the PR in more detail you did a great job of not adding any complexity to the core logic, so this shouldn't be too hard to merge.

[nabossha]

@noah-duncan thanks for the feedback. Would really appreciate a merge as there are multiple providers in Switzerland which over sovereign meeting-solutions based on Jitsi and they are becoming more popular quickly.