Released dmg and zip carry no stapled notarization ticket #650

Both artifacts on the releases page are notarized but unstapled, so Gatekeeper
has to ask Apple about them at first launch instead of reading the ticket out
of the download. On a machine that is offline, or whenever Apple's service is
unreachable, launching a freshly downloaded copy is refused.

Measured on the published 1.5.7 assets:

$ xcrun stapler validate GitX-arm64.dmg
GitX-arm64.dmg does not have a ticket stapled to it.

$ xcrun stapler validate GitX.app          # copied out of that dmg
GitX.app does not have a ticket stapled to it.

It is masked today because online verification succeeds:

$ spctl -a -vvv -t exec GitX.app
GitX.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: Farhan Ahmed (4RZN52RN5P)

Cause

The steps in .github/workflows/BuildPR.yml run in an order that throws the
stapling away:

1. Prepare artifact runs make package-signed, which produces
   GitX-<abi>.dmg and GitX-<abi>.zip.
2. Notarize App builds a separate GitX.zip with ditto and submits that.
3. Staple Notarization staples GitX.app and re-creates GitX.zip.
4. Upload dmg and Upload zip upload the two files from step 1, and the
   release job attaches those to the release.

The app stapled in step 3 only ever reaches GitX.zip, which nothing uploads.
The shipped dmg and zip were both sealed one step before the ticket existed.

Suggested shape of a fix

Staple the exported GitX.app once notarization returns, and package the dmg
and zip from the stapled app rather than before it, so make package-signed
runs after the stapler rather than ahead of it. Stapling the dmg itself as
well would cover a copy that is redistributed without being reopened.

Unrelated to the packaging bug in #649, which touches the same step but is
about zip -r dereferencing symlinks. Both can be fixed independently.