ci(release-manifest): record every TestFlight build when it processes

[bmc08gt]

The release manifest's testflight.build only moved when someone dispatched release-manifest.yml or ran deploy.yml with wait. Two of the three routes to TestFlight never recorded their build: the Xcode Cloud build a flipcash-* tag starts, and fastlane deploy run locally (what /deploy does). After flipcash-2026.10.3 the manifest stayed on 588, so TestFlight installs had nothing newer to report. A manual dispatch raised it to 589.

Each route now starts the same workflow, which waits for the build to process and then records it:

• release-manifest.yml runs on a pushed flipcash-* tag, and takes a wait input. With wait, fastlane update_release_manifest wait:true polls until a processed build newer than the manifest's exists (up to 75 min, minting a fresh token on each poll as wait_for_build_run does), then records it.
• fastlane deploy dispatches release-manifest.yml with wait=true right after it starts the Xcode Cloud build, whether or not it waits itself. The dispatch goes through gh and is best-effort: if it fails, the lane prints the command to run instead of failing the deploy. A dry run dispatches nothing.
• deploy.yml drops its own three manifest steps, since the lane now covers them, and gets actions: write so its GITHUB_TOKEN can dispatch.
• An hourly schedule stays as a backstop. The workflow's concurrency group keeps one pending run, so overlapping triggers can drop one, and a wait that times out records nothing. A run that finds nothing newer commits nothing. Removing the schedule block drops it.

Locally, fastlane update_release_manifest reports 589 and leaves the manifest alone; with the manifest set back to 588, wait:true wrote 589 straight away; fastlane deploy dry_run:true stops before the dispatch. The tag trigger and the dispatch from Actions only run on real events, so they haven't run yet.