Surface FFI panic events instead of silently dropping them

[MaxHeimbrock]

Summary

FfiEvent.Panic is the FFI layer's global unrecoverable-error notification, and Unity dropped it on the floor (DispatchEvent had case Panic: break; — a stub from an early protocol sync that was never wired). This PR surfaces panics through the disconnect path apps already handle.

What panic events are

The FFI sends Panic { message } (no room handle — it's global) from three kinds of places:

1. A spawned task panicked — watch_panic wraps essentially every FFI task (room event forwarding, stream tasks, the connect task, ...) and forwards the JoinError. The Rust comment: "Recommended behaviour is to exit the process."
2. A panic while handling a synchronous request (catch_unwind in cabi.rs).
3. Deliberate send_panic for state errors with no callback left to carry them — currently the ready-handshake timeout, which force-closes a room after ConnectCallback already went out.

After a panic the FFI's state is unreliable: a room whose event task died silently stops receiving events (including Disconnected itself — a zombie room), and in-flight async requests never complete (hung YieldInstructions).

Caveat worth knowing: release FFI binaries build with panic = "abort" (workspace Cargo.toml), so genuine Rust panics crash the process before any event is sent. In shipped builds this wiring covers the deliberate send_panic paths — including the ready-timeout zombie-room case — and it covers everything in local debug builds.

What this does

Since "exit the process" is not acceptable in Unity (Editor / shipped games), the panic becomes an observable disconnect:

• Log loudly via Utils.Error (works in Editor console and player logs; previously the only trace was a Rust-side log::error! that is invisible unless LK_VERBOSE).
• Cancel all pending callbacks so awaiting instructions (e.g. a mid-flight ConnectInstruction) resolve with IsError instead of hanging forever. Done before raising the event so requests issued by user handlers reacting to the panic (reconnect attempts) are not swept up.
• New internal FfiClient.PanicReceived event; each connected Room subscribes in OnConnect and tears itself down through the existing sequence: Disconnected, DisconnectedWithReason(UnknownReason), cleanup.

Deliberate trade-off: Panic carries no room identity and the FFI declares its whole state unreliable, so all live rooms are torn down — conservative, but it converts silent zombie state into the reconnect flow apps already implement.

Tests

• EditMode PanicEventTests: drives RouteFfiEvent with a synthetic panic from a non-main thread; asserts main-thread marshalling, PanicReceived payload, pending-callback cancellation (not completion), and entry removal.
• PlayMode PanicRoomTeardownTests (E2E): connects a real room, injects a synthetic panic through RouteFfiEvent, asserts Disconnected / DisconnectedWithReason(UnknownReason) fire and IsConnected goes false.
• LateJoinTrackSubscriptionTests re-run as connect-path regression guard.

All green locally against livekit-server --dev.

Follow-ups (not in this PR)

• Rust side: emit a proper Disconnected room event on the ready-timeout path, and/or reconsider the 15s ROOM_EVENT_READY_TIMEOUT.
• Upstream question: whether release builds should move to panic = "unwind" so real panics become observable events instead of process crashes (binary-size trade-off).

🤖 Generated with Claude Code