Add podspec publishing workflow

[pblazej]

Publishes LiveKitClient.podspec to livekit/podspecs on
release: published (plus manual dispatch), via the new
livekit/publish-cocoapod-action — pinned by
commit sha, same as publish-xcframework.yaml.

Our pods aren't on the trunk, so a release is a PR. The action clones the specs repo and runs
pod repo push --local-only, which leaves validation (--allow-warnings), the
Specs/<Pod>/<version>/ layout, the immutability guard (--no-overwrite) and the
[Add]/[Update] commit message to CocoaPods itself; the action only cuts the branch and opens
the PR. The same workflow drops into client-sdk-swift-xcframework,
livekit-uniffi-xcframework and webrtc-xcframework with only podspec: changed.

Before merging

• PODSPECS_PAT secret — needs contents: write + pull_requests: write on livekit/podspecs
• livekit/publish-cocoapod-action made public, matching publish-xcframework-action
• Re-pin to main once Keep dry-run off the remote publish-cocoapod-action#1 merges (keeps dry-run off the remote)

Xcode is pinned to 26.5, matching cocoapods-lint.yaml. Xcode 27 rejects deployment targets below iOS 15 / macOS 12 as an error, which fails validation of every LiveKit pod, so latest-stable would break once runners move to it. dry-run now defaults to true for anything other than a release or an explicit dry_run: false dispatch.

Sibling PRs: livekit/webrtc-xcframework#40, livekit/livekit-uniffi-xcframework#21, livekit/client-sdk-swift-xcframework#9. Each was dry-run on a real runner.

Tested

Against a scratch specs repo, running the action's step bodies directly:

case	result
LiveKitClient.podspec 2.17.0, full validation	passed (deps resolved from livekit/podspecs)
fixture pod, full flow	PR [Update] TestPod (0.0.4) → Specs/TestPod/0.0.4/TestPod.podspec
already-published version	fails: TestPod (0.0.1) already exists and overwriting has been disabled
dry-run	validates + commits locally, no branch, no PR
retry with the branch already on the remote	deletes and recreates it

Nothing was pushed to livekit/podspecs.

On folding the publish workflows together

Considered and I'd rather not, unless you disagree.

publish-docs, publish-xcframework and this one already share triggers, but folding them into
one workflow costs the ability to dispatch a single publisher. GitHub can re-run failed jobs, but
not one succeeded job — so re-publishing only docs after a release would re-run xcframework and
podspec too, and both of those fail hard on a second run by design. Getting that back means an
only: docs|xcframework|podspec|all input gating every job, which is more moving parts than the
duplication it removes.

That duplication is two lines per file — the ref/dry_run expression. Three focused files that
each work today, on a path that runs a handful of times a year, seem worth more than one file. Happy
to fold them if you'd rather have the single surface.

[github-actions]

⚠️ This PR does not contain any files in the .changes directory.

[devin-ai-integration]

Note

Newer findings are available below. Devin Review posted a newer report on this PR, in addition to the findings presented here.

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.