feat: add ios-expo reusable workflow for Expo apps

[morepriyam]

Summary

Adds .github/workflows/ios-expo.yml — an Expo counterpart to the existing
ios-meteor.yml. Wraps the ios@v1 composite action with Expo-specific
pre-steps so callers can build & ship to TestFlight with a single
uses: + secrets: inherit.

Pipeline: Xcode → Node → install JS deps → expo prebuild → CocoaPods →
Fastlane → TestFlight.

Why

ios-meteor.yml covers the Meteor/Cordova path. Expo apps need different
pre-steps (expo prebuild, JS package manager, no Meteor/Cordova). Today an
Expo caller would have to duplicate that boilerplate in their own workflow
and map every APPLE_* / MATCH_* secret by hand. With this workflow they
get the same one-liner experience the Meteor side already has.

jobs:
  testflight:
    uses: mieweb/sharedactions/.github/workflows/ios-expo.yml@v1
    secrets: inherit
    with:
      app_identifier: com.example.pulse

Inputs (defaults shown)

Input	Default	Notes
app_identifier	required	Must match app.json / Info.plist
xcode_path	/Applications/Xcode_26.3.app	Same default as ios-meteor.yml
node_version	20
package_manager	npm	npm | yarn | pnpm
working_directory	.	Path to the Expo project (where package.json lives)
signing_mode	match	match | secrets
upload_to_testflight	true

ios_build_dir is computed automatically from working_directory (Expo
prebuild lands the Xcode workspace in <working_directory>/ios, not the
default ios-build/ the composite expects for Cordova).

Scope

Expo only. The workflow assumes expo is in the caller's
dependencies. For bare React Native projects without expo, callers should
keep using the ios composite directly. The README is explicit on this.

Smoke test

Tested on a fork against a throwaway minimal Expo project before opening
this PR. Run: https://github.com/morepriyam/sharedactions/actions/runs/25014327554

Step	Result
Checkout	✓
Select Xcode (Xcode_26.3.app)	✓
Setup Node.js 20	✓
Install JS dependencies (npm ci)	✓
expo prebuild --clean --platform ios	✓
pod install	✓
Fastlane sign + archive + upload	✗ (expected — fork has no APPLE_* secrets)

The Fastlane step fails at app_store_connect_api_key.rb:43 because the
fork doesn't carry org-level APPLE_API_KEY_* secrets. That step is the
existing ios@v1 composite already exercised by ios-meteor.yml, so the
new code added by this PR (everything before Fastlane) is end-to-end
verified on a real macOS runner.

Total runtime: 2m16s.

Test plan

• Tag a new v1.x once merged (or move v1 forward, matching the
  existing convention)
• Wire into a real Expo repo with org secrets to confirm the Fastlane
  step also lands green end-to-end