The review notes name accounts that exist

This file handed Apple flamenetreview1 and flamenetreview2. Neither is an
account on the relay, and the users table says the only review accounts are
fnreviewalpha and fnreviewbeta, which are also the pair verified end to end
against the live accounts service on 2026-09-04. A reviewer typing a handle
that does not exist cannot get past the sign-in screen, which is the same
failure that had 0.4.0 rejected under Guideline 2.1.

The walkthrough was wrong in a second way. It sent the reviewer to a Community
tab to add the other account. There is no Community tab, and has not been: the
tabs are Home, Messages, Calls, Stories, Files, Wallet and Account, and adding
somebody happens from the field at the top of Home. The two accounts are
already contacts, so the step is not needed at all and the walkthrough is four
steps now rather than five.

Two checklist lines added. One for the Sign-In Information field, which is the
one thing a reviewer cannot work around. One for re-running generate.sh after a
version bump, because the version lives in project.yml and the Xcode project is
generated from it, so a bump alone archives the old number.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

TESTFLIGHT.md

@@ -48,25 +48,30 @@ https://flamenetmessenger.com
 ### Demo account
 
 ```
-Username:  flamenetreview1
-Password:  <in the password store — NOT in this repository>
+Username:  fnreviewalpha
+Password:  <in the password store, NOT in this repository>
 
 Second account (named in the Notes below):
-Username:  flamenetreview2
+Username:  fnreviewbeta
 Password:  <the same passphrase>
 ```
 
 The passphrase is deliberately not written here. This repository is
 public and these accounts are live; committing the value hands them to anyone.
-
-⚠️ **Which pair is current is not settled in this file.** The names above are
-`flamenetreview1` / `flamenetreview2`, and the pair verified end to end against
-the live accounts service on 2026-09-04, recorded on ios#12, was
-`fnreviewalpha` / `fnreviewbeta`. Both cannot be what App Store Connect holds.
-Check the Sign-In Information field before submitting and make this file agree
-with it. 0.4.0 was rejected under Guideline 2.1 over exactly this field.
 The tests read it from `FN_DEMO_PASSPHRASE`.
 
+These two are the pair that exists. This file used to say `flamenetreview1` and
+`flamenetreview2`, which are not accounts on the relay and have not been for
+some time: a reviewer typing those cannot get past the sign-in screen, which is
+the same failure that had 0.4.0 rejected under Guideline 2.1. Checked against
+the users table on 2026-09-15, `fnreviewalpha` and `fnreviewbeta` are the only
+review accounts there. `fnreviewalpha` / `fnreviewbeta` were also the pair
+verified end to end against the live accounts service on 2026-09-04, recorded
+on ios#12.
+
+Whatever is in the Sign-In Information field in App Store Connect has to match
+these two. That field is the one thing a reviewer cannot work around.
+
 The previous pair was burned and these replace them. The old passphrase
 was committed and later removed from the tree, but removing a secret from the
 tree does not remove it from history, and it remained readable in three commits
@@ -141,18 +146,21 @@ path and carry **no password at all**.
 >
 > The order matters, please start with the second account.
 >
-> 1. Sign in as **flamenetreview2** (password above). Wait for the Home tab to
+> 1. Sign in as **fnreviewbeta** (password above). Wait for the Home tab to
 >    load, then sign out from the Account tab. This registers this device for
 >    that account so it can receive encrypted messages; without it there is no
->    key to encrypt to and the send in step 4 will fail.
-> 2. Sign in as **flamenetreview1**.
-> 3. Go to the Community tab, search for **flamenetreview2**, open the profile and
->    add them.
-> 4. Return to Home, open the conversation and send a message.
-> 5. Sign out, then sign in again as **flamenetreview2**. The message is there.
+>    key to encrypt to and the send in step 3 will fail.
+> 2. Sign in as **fnreviewalpha**. The two accounts are already contacts, so
+>    **fnreviewbeta** is on the Home tab and in Messages with no adding to do.
+> 3. Open the **Messages** tab, tap the conversation with **fnreviewbeta**, and
+>    send a message.
+> 4. Sign out, then sign in again as **fnreviewbeta**. The message is there.
+>
+> To add somebody by hand instead, the field at the top of the **Home** tab
+> says "Search or add by username". There is no separate contacts screen.
 >
 > You may see a "Security keys changed" banner. That is the app working, it
-> appears when a contact signs in on a new device, which is exactly what step 5
+> appears when a contact signs in on a new device, which is exactly what step 4
 > does. Accept it to continue.
 >
 > **Voice and video calls** need two live devices; with one test device the call
@@ -244,7 +252,7 @@ was sent once, on 2026-09-15.
 ## 5. Before you hit submit
 
 - [x] Both demo accounts verified signing in through the app UI.
-- [ ] Walk the five steps above once on a real iPhone. Sign-in is proven; the
+- [ ] Walk the four steps above once on a real iPhone. Sign-in is proven; the
       full send-and-read round trip on one physical device is not.
 - [ ] `sudo xcode-select -s /Applications/Xcode.app`, you are pointed at
       **Xcode 27.0 beta in iCloud Drive**, and ASC rejects beta-Xcode builds.
@@ -255,7 +263,14 @@ was sent once, on 2026-09-15.
 - [ ] Privacy **nutrition label** under App Privacy, must agree with
       `Resources/PrivacyInfo.xcprivacy`.
 - [ ] Age rating set.
-- [ ] `CURRENT_PROJECT_VERSION` bumped since the last upload.
+- [ ] Sign-In Information in App Store Connect says `fnreviewalpha` and the
+      passphrase those accounts actually take. A handle that does not exist is
+      what had 0.4.0 rejected.
+- [ ] `CURRENT_PROJECT_VERSION` bumped since the last upload, **and
+      `Scripts/generate.sh` re-run afterwards**. The version lives in
+      `project.yml` and the Xcode project is generated from it, so a bump
+      without a regenerate archives the old number and Xcode goes on showing
+      it.
 - [ ] `FN_APNS_ENV` on the relay matches where the build is going.
       `production` for TestFlight and the App Store, `sandbox` for a build
       installed from Xcode. It is per-relay, not per-token, so one relay cannot