Bump livekit-api from 0.6.3 to 0.8.1 in the livekit-crates group across 1 directory

[dependabot]

Bumps the livekit-crates group with 1 update in the / directory: livekit-api.

Updates livekit-api from 0.6.3 to 0.8.1

Release notes

Sourced from livekit-api's releases.

livekit-api 0.8.1 (2026-09-24)

Fixes

• refactor(signaling): explicit signal lifecycle state machine - #1402 (@​lukasIO)
• Upgrade to prost 0.14 across the whole project - #1447 (@​1egoman)

livekit-api 0.8.0 (2026-09-22)

Breaking Changes

VideoGrants gains the agent grant and Claims the kind claim (with

AccessToken::with_kind), which the Go, Python and JS SDKs already carry. An agent worker's token is VideoGrants { agent: true } and a simulated job's participant token is kind: "agent"; neither could be minted from Rust before. livekit-uniffi exposes both: TokenOptions.kind, Claims.kind, and agent on its VideoGrants record.

Breaking: the four grants the server infers when absent -- can_publish, can_subscribe, can_publish_data, can_update_own_metadata -- are now Option<bool>, as in the Go and JS SDKs. None leaves the decision to the server, and the new getters (can_publish(), can_subscribe(), can_publish_data(), can_update_own_metadata()) read a token the way the server does, can_publish_data falling back to can_publish included. Code that set these fields writes Some(..); code that read them uses the getters. The same fields are optional on the livekit-uniffi record, and livekit-api re-exports the crate as livekit_api::access_token, so both carry the change.

Nothing at its default is written into the token any more: unset claims and grants are omitted, as the server's own omitempty grants are. Verification of existing tokens is unchanged.

Fixes

Report the reconnect reason to the server when resuming.

Resumes previously sent no reason, so server-side telemetry could not attribute why Rust clients reconnect — every resume looked like RR_UNKNOWN. The engine now records what caused the episode (signal disconnected, publisher failed, subscriber failed) and reports it on each resume attempt. The v0 signalling path was also missing the reconnect_reason query parameter entirely, so it would not have been reported even if a reason had been supplied.

livekit-api 0.7.1 (2026-09-09)

Fixes

• log warning if signal messages get dropped during reconnect - #1391 (@​lukasIO)

livekit-api 0.7.0 (2026-09-08)

Breaking Changes

... (truncated)

Commits

• 2dd762d Release packages (#1455)
• bbcb62c fix(webrtc-sys): avoid panics on non-ASCII RTC error headers (#1466)
• c20fa7c Migrate the SoxResampler to be exposed via Uniffi as well as by protobuf (#1421)
• 0ea435c fix(changeset): drop the duplicate livekit-uniffi key blocking the livekit-pr...
• 7e901ba Workspace dependency visualization (#1460)
• d66d86f refactor(signaling): explicit signal lifecycle state machine (#1402)
• 5539863 Downgrade Java version of libwebrtc (#1456)
• 74f8a3d chore(uniffi): format generated Swift bindings with swiftformat (#1454)
• 5a656c4 Release packages (#1423)
• c13104f Fix livekit-datatrack version (#1450)
• Additional commits viewable in compare view