LiveRoom is a standalone model, not a subtype of ChatRoom or Space

Live streaming and meeting rooms have their own model (LiveRoom) independent of ChatRoom and Space. A LiveRoom belongs to a Community, optionally links to a Space and/or ChatRoom, but is not a content type within a Space like Post or Event.

Considered Options

• LiveRoom as a Space type: Add a live value to Space.space_type. Would reuse the existing space permissions and sidebar. But LiveRooms have fundamentally different lifecycle (backstage→live→ended), different metadata (host capacity, recording, provider config), and need to exist independently of a Space's CRUD lifecycle.
• LiveRoom under ChatRoom: Make LiveRoom a flag on ChatRoom. Shares the real-time infrastructure. But a meeting room is not a conversation — it has scheduled start/end, recording, view types, and access control that don't map to ChatRoom's message model.
• Standalone LiveRoom (chosen): Its own model with its own lifecycle, permissions, and API endpoints. Optionally links to a Space for navigation and a ChatRoom for companion chat.

Why standalone was chosen

• LiveRoom's lifecycle — backstage (prep), live (active), ended (archived) — does not fit any existing model.
• Different room providers (LiveKit, Owncast, etc.) may be swapped in without affecting Space or ChatRoom models.
• Companion chat is optional and uses a separate ChatRoom reference (chat_room_uuid), not an embedded message list.

Consequences

• LiveRoom needs its own permission checks (not automatically covered by Space or Community role).
• The Space link is nullable — LiveRooms can exist outside the sidebar structure (e.g., a community-wide town hall).
• Multiple LiveRooms can coexist per Community, but only one should be "live" at a time for a given Space (enforced at the application layer, not the database).