Correct when the version guard fires relative to xcodes

Task 6 Step 3 asserted the guard must fail before xcodes runs. It cannot:
fastlane's before_all always executes before the lane body, and the plan puts
xcodes in before_all and the guard in the lane. The acceptance criterion was
unmeetable on any machine.

The guard still does what it exists for — aborting before the ~30 minutes of
signing — so the wording was wrong, not the pipeline. Also record that the step
needs the xcodes CLI, since without it the lane dies earlier with an error that
reads like a config problem.

docs/superpowers/plans/2026-07-15-healthchat-appstore-release.md

@@ -603,8 +603,12 @@ Expected: lists `ios release_testflight` with its description. A Ruby syntax err
 
 - [ ] **Step 3: Verify the version guard rejects a marker version**
 
+Run: `brew bundle` first if you have never run it here — this step needs the `xcodes` CLI, for the reason below.
+
 Run: `bundle exec fastlane release_testflight marketing_version:26.07.3-rc1`
-Expected: fails immediately with `'marketing_version' must be 1-3 dot-separated integers`. This is the guard doing its job — it must fail *before* `xcodes` runs.
+Expected: fails with `'marketing_version' must be 1-3 dot-separated integers`, before any build or signing work.
+
+**On ordering.** fastlane's `before_all` always runs before the lane body, so `xcodes` selects the Xcode version *first* and the guard fires immediately after — not before. That still saves the ~30 minutes of signing the guard exists to prevent, which is the point, but it means this step needs the `xcodes` CLI present (it is in `Brewfile`). Without it the lane dies at line 10 with `Invalid default value for binary_path` — a missing-tool error, not a guard failure. Do not restructure the Fastfile to make the guard literally run first; `before_all` pinning the toolchain is the convention the legacy pipeline uses too.
 
 - [ ] **Step 4: Commit**