Preserve WebRTC linkage in macOS releases

[abnormal749]

Summary

Fix the macOS arm64 release crashing during WebRTC initialization when starting an interview:

+[NSString stringForAbslStringView:]: unrecognized selector

The release workflow sets RUSTFLAGS to an empty string on macOS. This overrides the Apple-specific flags in .cargo/config.toml, dropping -ObjC and allowing the linker to omit WebRTC's Objective-C categories.

Explicitly set RUSTFLAGS to -Clink-arg=-ObjC for aarch64-apple-darwin in the release job. The existing Windows and Linux flag values remain unchanged.

Fixes #45. The same crash signature is reported in LiveKit #795.

Validation

• Reproduced the crash with the published macOS binary.
• Built the fixed macOS release successfully:

  RUSTFLAGS=-Clink-arg=-ObjC cargo build --release --locked --target aarch64-apple-darwin

• Passed the same native initialization check with the rebuilt binary: WebRTC reached a local mock LiveKit endpoint and handled its HTTP 401 response without aborting.
• Confirmed with otool that the rebuilt binary includes the stringForAbslStringView: category method.
• Passed actionlint and verified the workflow expression's flag values for all three release targets.

Windows and Linux binaries were not built locally.

---

Summary by cubic

Fixes macOS arm64 release crashes during WebRTC initialization with +[NSString stringForAbslStringView:]: unrecognized selector. The release job previously cleared RUSTFLAGS, overriding .cargo/config.toml and letting the linker drop WebRTC's Objective-C categories. It now sets -Clink-arg=-ObjC for Apple targets, and the workflow rejects the binary before packaging if the stringForAbslStringView: category is missing. Windows and Linux flag values are unchanged.

^{Written for commit a2e5c7a. Summary will update on new commits.}

[ColtenOuO]

      # Override the workflow-wide Linux-only mold flag with the
      # platform-specific flags required by each release target.
      # Even an empty RUSTFLAGS...

Nit: This might make the comment more completely describe what it actually does.

[jserv]

Nothing in this workflow proves the flag reached the linker. A build without -ObjC still links cleanly, so the next edit to this expression republishes a macOS binary that aborts at the first room, and the build job is skipped on pull requests (it ran as skipping here), so the regression surfaces in a user's download rather than in CI. Worth a follow-up next to the Linux floor checks that already guard that leg: a macOS-only step before packaging that greps otool -oV on the built binary for stringForAbslStringView:.

[abnormal749]

Thanks for pointing this out. I added the check to the macOS build before packaging and tested it against both binaries.
The old binary still contains the selector reference, so a plain grep would pass it too. The check matches the method entry in otool output, which catches the old crashing release and lets the fixed one through.

[ColtenOuO]

LGTM. Let's wait for CI to be approved and turn green.

[jserv]

Thank @abnormal749 for contributing!