HMAC-only JWT provider to shrink binaries

[pblazej]

Summary

LiveKit access tokens are HS256, yet livekit-api pulled jsonwebtoken's full
rust_crypto backend (RSA/EC/EdDSA). This swaps it for a minimal in-crate HMAC
CryptoProvider, dropping ~200 KiB of unreachable crypto from every shipped
binary. No public API or behavior change.

Also removes the now-obsolete nightly/build-std CI step for tvOS/visionOS —
both are Tier 2 with prebuilt std now.

Size impact

Slice	Before	After	Δ
RustLiveKitUniFFI iOS arm64 framework	~900 KiB	672 KiB	−227 KiB (−25%)
liblivekit_uniffi Android arm64-v8a .so	~1157 KiB	816 KiB	−340 KiB (−29%)

iOS bloaty diff is almost entirely code: __TEXT,__text −186 KiB, __TEXT,__const
(EC/RSA constant tables) −44 KiB. livekit-ffi/livekit benefit too.

Size guards tightened to 5% over the measured artifacts: iOS
SPM_SIZE_LIMIT_BYTES 1 MiB → 723467; Android ANDROID_SIZE_LIMIT_BYTES
1.5 MiB → 877918.

Why a custom provider

jsonwebtoken 10 resolves its backend through a process-global CryptoProvider,
and new_signer/new_verifier statically reference every algorithm — so the
linker can't dead-strip RSA/EC/EdDSA; only feature removal works. The
EncodingKey/DecodingKey::try_get_hmac_secret() accessors and the
JwtSigner/JwtVerifier traits are public, so an HS256/384/512 provider is
~40 lines, installed idempotently on first sign/verify.

Alternatives considered

• Per-crate feature gate (livekit-uniffi requests livekit-api without
  rust_crypto): doesn't work — cargo compiles livekit-api once with the
  workspace-union of features, and livekit/livekit-ffi request the defaults,
  so rust_crypto stays linked regardless.
• livekit-uniffi as its own workspace: excluding it from the root workspace
  would isolate feature resolution, making a per-crate gate work without
  changing the published livekit-api default. Rejected — a larger structural
  change (explicit path deps instead of workspace = true, separate
  Cargo.lock) for no extra savings over the default swap, which is safe here
  since everything is HS256.
• Drop services-tokio/reqwest, gate os_info/device-info, trim
  livekit-protocol: ~0 binary impact — bloaty shows these are already
  dead-stripped (nothing in the token path references them).
• build-std for iOS: ~27 KiB more (the __eh_frame unwinding tables from
  the prebuilt panic=unwind std), but needs nightly for the primary slice.
  Deferred.

Safety

• The access-token API is HS256-hardcoded and jsonwebtoken is not
  re-exported, so RSA/EC/EdDSA were never reachable — removing them changes no
  public behavior.
• No "missing provider" crash: the provider is installed via Once at all
  three entry points (to_jwt, verify, from_unverified) before any
  encode/decode. Unsupported algorithms return a clean Err, never a panic.
• Only residual: the process-global install_default() could conflict with an
  app that separately uses jsonwebtoken-10 for non-HS256 JWTs in the same
  process — narrow, and documented in jwt_provider.rs.

Validation

• cargo test -p livekit-api passes (sign / verify / unverified-decode).
• livekit-ffi compiles unchanged.
• Real iOS framework + Android AAR built and measured; both size gates pass.
• Full xcframework build on the pinned stable 1.96.0 confirms tvOS/visionOS use
  prebuilt std (no -Zbuild-std, no recompiled core/std on any slice).

🤖 Generated with Claude Code

[github-actions]

Changeset

The following package versions will be affected by this PR:

Package	Bump
livekit-api	patch

[ladvoc]

LGTM ✅