Fix iOS CI toolchain drift and default-branch triggers

[zack-dev-cm]

Summary

The iOS example workflow follows macos-latest and its default Xcode. On unchanged upstream a2a81ce, Xcode 26.6 fails in React Native's fmt dependency with consteval compilation errors. The same Debug iphoneos command succeeds with Xcode 26.2.

Pin the iOS job to macos-15 and Xcode 26.2, retaining the iOS 26 SDK required by the current capture APIs. Ruby 2.7.4, dependency bootstrap and the device build command are unchanged.

Also add master, the repository's default branch, to the Build and Linter push filters, which currently list only main. Pull-request triggers are retained. This workflow-only correction is independent of the Android fixes in #812, #813 and #817; the four-PR merge guide records their integration.

How did you test this change?

• Hosted reproductions of the exact upstream Debug/device build pass on unchanged baseline and independently on Map Android barcode bounds into the visible scan frame #812 and Reuse and close Android barcode scanners without leaking shared images #813 with Xcode 26.2. The default-Xcode baseline reproduction fails.
• Both workflow files parse, retain pull-request triggers and match pushes to main and master. Android build steps are unchanged.
• The macOS 15 runner inventory lists /Applications/Xcode_26.2.app and the iOS 26.2 SDK.

Upstream Build and Linter jobs still require maintainer approval. The separate public integration validation covers Android; it does not establish a new iOS build result.

[zack-dev-cm]

Could a maintainer approve the pending Build and Linter workflows here and on #812, #813 and #817? This PR isolates the iOS toolchain and default-branch CI correction; the Android changes remain independently reviewable. The submitted heads are unchanged, and upstream CI would complement the validation described above.