[ryanbr]

What this PR does

Two leftovers from 749c94118, which gave the iOS family the production bundle id.

1. The iOS app was named "NOOP Staging". 749c94118 dropped the .staging suffix from every iOS-family bundle id, with its reason stated outright: iOS has no App Store app to install beside (NoopApp is closed), so the overlay served no purpose there and only broke sideloading via AltStore. It enumerated the ids it changed and never reached PRODUCT_NAME, which has read "NOOP Staging" since 719477a8d. That setting sits in the target's base block with no per-configuration override, so every iOS build including the signed release produced NOOP Staging.app with an executable to match, under a production bundle identifier. By that commit's own reasoning the name serves no purpose on iOS either.

2. Both fork workflows told iOS users the wrong thing about their data. The release footer and the testing-build notes each announced "NOOP Staging identity, installs beside the official app (separate data)" for all three platforms at once. Since 749c94118 that is false for iOS: it carries the production id, so a sideload replaces an installed official app and uses its data. Android (.staging via -PstagingRelease) and macOS (.noop.staging, kept deliberately per #39) genuinely do install beside. The claim is now made per platform, and the iOS line says plainly that it replaces, since believing the old wording could cost someone data they expected to be left alone.

Type of change

• Bug fix (build identity and user-facing release copy)

Blast radius checked

macOS is untouched and still consistent with itself (.noop.staging + "NOOP Staging"). Nothing keys off the iOS product name:

• WKCompanionAppBundleIdentifier resolves from the bundle id, not the product name.
• StrandTests's TEST_HOST points at the macOS NOOP Staging.app, not the iOS bundle, so it still tracks the target it hosts.
• StrandiOS/Resources/Info.plist already set CFBundleName and CFBundleDisplayName to NOOP, so the home-screen label does not change. What changes is the .app directory name and CFBundleExecutable.
• Both workflows locate the built bundle by a *.app glob, so packaging is unaffected.

How it was tested

• All three edited files parse, and the resulting identities were read back from the parsed project.yml: NOOPiOS is now $(BUNDLE_ID_PREFIX).noop + NOOP, Strand stays $(BUNDLE_ID_PREFIX).noop.staging + NOOP Staging.
• The Apple compile is what matters here, so this is deliberately a PR rather than a direct commit: app-build.yml path-matches project.yml and runs both Apple legs on the PR head.

Not claimed

This is not offered as the cause of the Apple Health symptom in #2514. The shipped plist already carried NOOP for both display keys, so what Apple Health actually reads for that source name is still unestablished, and the test that would settle it is a fresh install on a device that has never had NOOP.

Related issues

Refs #2514