It seems to me that we are re-using the tags that were used to created the TestFlight releases (and which was approved by Apple), and we do not create a new tag.
In other words we do want to re-create the very same macOS build for FTP, as part of the GitHub release process, so we pointing it to the (Apple approved) TestFlight tag.
(In case of a TestFlight build, the trigger is the appropriate tag. In case of the release, the trigger is the release itself.)

To me the workflow should be as such:

• Tag testflight when you want to do Testflight release. If this tag already exists, then removes/superseeds older version.
• If we make a release, then tag x.y.z and release in GitHub.
• Releasing a version triggers the publishing to testflight but only such a version should make it through production.
• If there is a problem with Apple validation - so post GitHub release - then a patch release has to be made.

I've updated the readme and the CD workflow to reflect the above requirements.