Desktop voice-agent clients (and any compatible UI) expect JSON-encoded
agent:* events on the LiveKit data channel to drive UI state: listening
indicator, live user transcript, thinking/speaking indicators, and
conversation log updates.

Emit six events at the appropriate lifecycle points:
- agent:listening-start  — VAD detects speech onset (revert if too short)
- agent:listening-stop   — silence threshold reached or false alarm
- agent:user-transcript  — final ASR result (with transcript + identity)
- agent:thinking-start   — just before LLM invocation
- agent:speaking-start   — first TTS frame published
- agent:speaking-stop    — playback finished (or errored)
- agent:agent-transcript — mirror of every send() payload as the
                           assistant's final text, so clients can render
                           the conversation log

Events go out on the default (unnamed) data topic so desktop's topic
router (topic == "hermes-chat" -> plain text, else -> JSON event)
decodes them correctly; "hermes-chat" is still used for the raw text
mirror from send().

Event publishes are wrapped in try/except + logger.debug — UI telemetry
must never break the voice flow.

Three related optimizations so the LiveKit adapter stops holding a
participant slot when nobody's there to talk to:

1. Presence polling (lazy join):
   - connect() now calls RoomService.list_participants() via livekit-api.
     If the room is empty, the adapter does not join — instead it starts
     _presence_watch_loop, a 30s poll that joins as soon as a remote
     participant appears.
   - Adapter still reports connected to the gateway so send/receive code
     paths work when the room is occupied.

2. Auto-leave when alone:
   - _on_participant_disconnected checks self._room.remote_participants.
     If it's empty, _leave_and_watch tears down the room connection,
     cancels the silence task and audio streams, and re-arms the
     presence watcher.
   - Added a _graceful_leave flag so that room.disconnect() triggered
     by leaving intentionally does not also kick off _reconnect_loop.

3. Reconnect retries capped at MAX_RECONNECT_ATTEMPTS (10):
   - Previously _reconnect_loop retried forever with a 60s ceiling.
     A misconfigured LIVEKIT_URL would spam retries until the process
     was restarted. Now we log an error and go idle after the cap.
   - _reconnect_loop now calls _join_room (the pure room-join body)
     rather than the public connect() entry, so a reconnect doesn't
     re-trigger presence polling.

Also: silence-detection loop now uses a 2s interval when no participants
are buffered (was always 200ms), saving a tiny bit of CPU during idle
windows and while presence polling is waiting for someone to arrive.

The old connect() body was extracted into _join_room() — same logic,
different name — so presence polling and reconnect can reuse it.

…, env override

LiveKit Cloud has real rate limits and per-minute billing, so 30s between
presence checks is a sensible default. Self-hosted LiveKit has neither
constraint, so 5s keeps the first-speaker wait short.

Detection is by URL: hostname containing ".livekit.cloud" picks the
cloud cadence, anything else picks the local cadence.

LIVEKIT_PRESENCE_POLL_INTERVAL (seconds, float) overrides either default
for users with unusual deployments. The setup wizard now prompts for it
with an "empty = auto" hint.

Resolved once at adapter construction and logged so the operator can
see which cadence is in effect and why.

The earlier commit that added _resolve_presence_poll_interval inserted
the new method's body between __init__'s presence_poll_interval call and
the trailing init lines (_audio_buffers, _last_audio_time, _audio_streams,
_paused, _speaking_participants). The trailing lines ended up *after*
the method's `return interval` and so were never executed.

Symptom: every participant_disconnected event raised
  AttributeError: 'LiveKitAdapter' object has no attribute '_audio_streams'
inside _cleanup_participant. Because the AttributeError aborted the
event handler before the auto-leave check, the room never tore down
when the last human left.

Move the orphaned init lines back into __init__ where they belong, so
the dicts and flags exist on the instance.

_process_voice_input was importing a function that doesn't exist in
tools.transcription_tools, which raised ImportError on every utterance
and silently aborted the voice pipeline (no transcript, no LLM call,
no TTS reply).

transcribe_audio already resolves the model from stt config internally
when called with no model arg — that's the pattern gateway/run.py and
gateway/platforms/discord.py use. Drop the bogus import + helper call
and let transcribe_audio do its thing.

Two bugs blocked end-to-end speech on a freshly-joined LiveKit room:

1. _cleanup_participant dropped the audio buffer the instant the track
   unsubscribed — fine for permanent leaves, but it also fires when a
   participant's mic transiently drops or, for file-based publishers,
   when the clip ends. VAD never reached its silence-threshold trigger
   on the unfinished utterance, so the user's last words were lost.
   Flush the pending utterance (if it meets MIN_SPEECH_DURATION after
   trailing-silence trim) through _process_voice_input before tearing
   down state, so the words still reach STT.

2. voice.auto_tts is False by default — correct for text platforms
   like Discord/Slack where TTS is opt-in, wrong for LiveKit where
   the channel itself is audio. A typed-only reply gives the LiveKit
   user nothing. Override _should_auto_tts_for_chat in LiveKitAdapter
   so it defaults to True; per-chat /voice off via
   _auto_tts_disabled_chats still wins.

End-to-end test: probe joins the room, publishes a 5s utterance,
hears Avery reply with cloud OpenAI TTS through the LiveKit audio
track. Confirmed listening-start, listening-stop, user-transcript,
thinking-start, speaking-start, speaking-stop all fire in order with
real audio frames published back.