Install the bare fixture's pods through bundler

[janicduplessis]

Description

The bare-iOS fixture setup ran plain pod install. On an rvm machine, RubyGems' Gemfile-aware activation reads the RN template's Gemfile from cwd and fails its constraint resolution with Gem::GemNotFoundException — reproduced with cd <fixture>/ios && pod --version, while BUNDLE_GEMFILE=/dev/null pod --version succeeds. CI never sees it (no rvm). Beyond the crash, plain pod also dodges the version pins the template's Gemfile exists to enforce, which is the same pod-version-skew class that makes committed Podfile.locks unreproducible across machines.

Solution

The fixture-setup step impersonates the developer who created the app, and the template's own printed instructions are bundle install + bundle exec pod install — so do exactly that, before the fixture's initial commit (the Gemfile.lock lands in the fixture like a real repo). Bundler-first with a hard fail rather than a plain-pod fallback: a fixture whose pods cannot be pinned is not the fixture the template describes.

Scope note: this changes only harness fixture setup. Stim's product behavior (plain pod install in engine/deps.ts, with its curated error taxonomy) is deliberate and untouched — though doctor's human remedy says bundle exec while the engine runs plain pod, which is a product question worth its own issue someday.

Test plan

• To attach before ready: a full loop bare-ios run on the rvm machine that reproduced the failure, expecting green through the bundler path.
• CI's bare-iOS jobs exercise it on every nightly.

Fixes #133

---

Validation evidence (attached per review)

• Live run green on the rvm machine that reproduced the failure: loop bare-ios completed exit 0 (2026-08-31T17:33-17:38Z), through bundle install -> bundle exec pod install at fixture setup and a full worktree loop after it.
• The review's [High] concern — the product's own plain pod install hitting the same activation failure — did not materialize: the same run's worktree builds ran engine/deps.ts's plain pod (no BUNDLE_GEMFILE neutralization in the env) and passed. The harness-context failure evidently needs the shell/hook context; stim's no-shell spawn does not trip it. No companion change needed on this evidence.
• Real reproduction transcript (previously failing fixture-setup, plain pod, rvm ruby 3.4.8):

  Gem.find_spec_for_exe': can't find gem cocoapods (>= 0.a) with executable pod (Gem::GemNotFoundException)
    from .../rubygems.rb:288:in 'Gem.activate_bin_path'
    from ~/.rvm/gems/ruby-3.4.8/bin/pod:25:in '<main>'
  

  Real fixture Gemfile (RN 0.87 template): ruby ">= 2.6.10", gem 'cocoapods', '>= 1.13', '!= 1.15.0', '!= 1.15.1', gem 'activesupport', '>= 6.1.7.5', '!= 7.1.0'. Reproducible on this machine with cd <fixture>/ios && pod --version; BUNDLE_GEMFILE=/dev/null pod --version succeeds.
• CI: the ios e2e job now runs ruby/setup-ruby@v1 (ruby 3.4) so bundler and a Gemfile-satisfying ruby exist on the runner; previously the harness leaned on the image's preinstalled CocoaPods.