Feature Request: Auto-close room when only 1 participant remains for N seconds

Is your feature request related to a problem? Please describe.

LiveKit currently supports several room-lifecycle timeouts (empty_timeout, departure_timeout, max_duration), but none of them handle the common case of a room being left with exactly one remaining participant (e.g. everyone else hung up, or the other side never joined) for an extended period.

Today the only way to enforce this is by building custom infrastructure outside of LiveKit: subscribing to participant_joined/participant_left webhooks (or agent events), tracking per-room participant counts, and running a timer to call DeleteRoom if the count stays at 1. This works, but it's non-trivial to build reliably (needs to survive restarts, work across multiple server instances, re-check state right before acting, etc.) for what is a fairly common requirement — e.g. calls where one side didn't join, or one participant left and forgot to hang up, are quietly kept alive (and billed/streamed) indefinitely.

Describe the solution you'd like

Add a new room configuration option, e.g. solo_timeout (or single_participant_timeout), settable at room creation via the Server API:

room_service.CreateRoom(CreateRoomRequest{
    Name: "my-room",
    SoloTimeout: 120, // seconds — close room if only 1 participant remains this long
})

Behavior:

• Starts a timer when participant count transitions to exactly 1.
• Timer resets/cancels if a participant joins (count > 1) or the room becomes empty (handled by existing empty_timeout).
• If the timer expires while count is still exactly 1, the room is closed the same way max_duration closes it today (with the same webhook events, e.g. room_finished).

Describe alternatives you've considered

• max_duration: works as a blanket cap but ends calls even when multiple participants are actively present — not equivalent.
• Custom webhook + timer service: functionally achievable today, but requires building and operating an extra stateful service (or Redis-backed job queue) just to replicate what feels like a natural extension of the existing timeout family.
• LiveKit Agents in every room: an agent could watch room.remote_participants and call delete_room on timeout, but this only works for deployments that already run an agent in every room, and isn't a general solution for plain SFU usage.

Additional context

This would sit naturally alongside the existing empty_timeout / departure_timeout / max_duration room options in CreateRoomRequest, reusing the same "close room" mechanism internally.