macOS x86_64 FreeCAD 1.1.1 app is signed but rejected by Gatekeeper as unnotarized

### Problem description

Hi FreeCAD maintainers,

First, thank you for all the work you put into FreeCAD and for continuing to provide macOS builds for both Apple Silicon and Intel users. I’m reporting this because it appears to affect automated macOS deployment workflows, not because I think anything here was intentional. The x86_64 build seems to be signed by the expected FreeCAD Developer ID, but Gatekeeper currently rejects it as unnotarized.

## Summary

The current macOS Intel/x86_64 release artifact for FreeCAD 1.1.1 appears to be signed with the expected FreeCAD Developer ID Team ID, but fails Gatekeeper assessment because it is reported as unnotarized.

This affects automated deployment tools such as Installomator and AutoPkg, which intentionally verify macOS software before installing or packaging it for managed fleets.

## Affected Artifact

Release: FreeCAD 1.1.1

Artifact:

```text
https://github.com/FreeCAD/FreeCAD/releases/download/1.1.1/FreeCAD_1.1.1-macOS-x86_64-py311.dmg
```

The Apple Silicon artifact appears to pass the same check:

```text
https://github.com/FreeCAD/FreeCAD/releases/download/1.1.1/FreeCAD_1.1.1-macOS-arm64-py311.dmg
```

## Reproduction Steps

```bash
tmpDir=$(mktemp -d)
trap 'rm -rf "$tmpDir"' EXIT

downloadURL="https://github.com/FreeCAD/FreeCAD/releases/download/1.1.1/FreeCAD_1.1.1-macOS-x86_64-py311.dmg"

curl -fsL "$downloadURL" -o "$tmpDir/freecad-x86_64.dmg"
file "$tmpDir/freecad-x86_64.dmg"

mountPoint=$(hdiutil attach "$tmpDir/freecad-x86_64.dmg" -readonly -nobrowse -noverify | awk '/\/Volumes\//{print substr($0, index($0, "/Volumes/")); exit}')
appPath="$mountPoint/FreeCAD.app"

echo "CFBundleVersion=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' "$appPath/Contents/Info.plist")"
spctl -a -vv "$appPath"
codesign -dv "$appPath" 2>&1 | awk -F= '/^TeamIdentifier=/{print "TeamIdentifier=" $2}'

hdiutil detach "$mountPoint" -quiet
```

## Actual Result

```text
CFBundleVersion=1.1.1
/Volumes/FreeCAD 1/FreeCAD.app: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: The FreeCAD project association (289DJRF23X)
TeamIdentifier=289DJRF23X
```

## Why This Matters

This is not only a first-launch user experience issue. It blocks automated macOS deployment workflows.

Installomator verifies downloaded apps with `spctl -a -vv` before installation and exits if Gatekeeper rejects the app:

https://github.com/Installomator/Installomator

AutoPkg is commonly used by Mac admins to automate downloading, verifying, packaging, and deploying third-party macOS software:

https://github.com/autopkg/autopkg

When a release is signed by the correct Developer ID but not accepted by Gatekeeper, deployment recipes and labels either fail or require unsafe local exceptions. That creates extra maintenance burden for open source deployment projects and for Mac admins who are trying to deploy FreeCAD in labs, schools, universities, and managed environments.

## Relevant Apple Documentation

Apple’s notarization overview:

https://developer.apple.com/documentation/security/notarizing-macos-software-before-distribution

Apple platform security guide for macOS app signing:

https://support.apple.com/guide/security/app-code-signing-process-sec3ad8e6e53/web

Apple documentation for command-line notarization workflows with `notarytool`:

https://developer.apple.com/documentation/security/customizing-the-notarization-workflow

## Suggested Fix

Please re-check the notarization pipeline for the macOS x86_64 DMG/app bundle and republish the x86_64 artifact after successful notarization.

A typical validation check before publishing would be:

```bash
spctl -a -vv "/path/to/FreeCAD.app"
codesign -dv "/path/to/FreeCAD.app" 2>&1 | awk -F= '/^TeamIdentifier=/{print "TeamIdentifier=" $2}'
```

For a distributable DMG, it is also useful to validate after mounting the final uploaded DMG, not only before packaging, because deployment tools evaluate the final artifact users download.

Thanks for maintaining FreeCAD. This kind of release-signing issue is easy to miss, but fixing it would make the macOS builds much easier to deploy safely at scale.

### Workbench affected?

Other (specify in description)

### Steps to reproduce

## Reproduction Steps

```bash
tmpDir=$(mktemp -d)
trap 'rm -rf "$tmpDir"' EXIT

downloadURL="https://github.com/FreeCAD/FreeCAD/releases/download/1.1.1/FreeCAD_1.1.1-macOS-x86_64-py311.dmg"

curl -fsL "$downloadURL" -o "$tmpDir/freecad-x86_64.dmg"
file "$tmpDir/freecad-x86_64.dmg"

mountPoint=$(hdiutil attach "$tmpDir/freecad-x86_64.dmg" -readonly -nobrowse -noverify | awk '/\/Volumes\//{print substr($0, index($0, "/Volumes/")); exit}')
appPath="$mountPoint/FreeCAD.app"

echo "CFBundleVersion=$(/usr/libexec/PlistBuddy -c 'Print :CFBundleVersion' "$appPath/Contents/Info.plist")"
spctl -a -vv "$appPath"
codesign -dv "$appPath" 2>&1 | awk -F= '/^TeamIdentifier=/{print "TeamIdentifier=" $2}'

hdiutil detach "$mountPoint" -quiet

### Expected behavior

## Expected Result

The x86_64 app should be accepted by Gatekeeper:

```text
FreeCAD.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: The FreeCAD project association (289DJRF23X)
TeamIdentifier=289DJRF23X
```

### Actual behavior

## Actual Result

```text
CFBundleVersion=1.1.1
/Volumes/FreeCAD 1/FreeCAD.app: rejected
source=Unnotarized Developer ID
origin=Developer ID Application: The FreeCAD project association (289DJRF23X)
TeamIdentifier=289DJRF23X
```

### Development version About Info (in Safe Mode)

```shell
Download link: https://github.com/FreeCAD/FreeCAD/releases/download/weekly-2026.06.03/FreeCAD_weekly-2026.06.03-macOS15-arm64.dmg

spctl -a -vv --type exec "/Volumes/FreeCAD 1/FreeCAD.app"
/Volumes/FreeCAD 1/FreeCAD.app: accepted
source=Notarized Developer ID
origin=Developer ID Application: The FreeCAD project association (289DJRF23X)

xcrun stapler validate "/Volumes/FreeCAD 1/FreeCAD.app"
Processing: /Volumes/FreeCAD 1/FreeCAD.app
FreeCAD.app does not have a ticket stapled to it.

This means the app is notarized and accepted by Gatekeeper, but the app bundle itself does not contain a stapled notarization ticket.

What can fail is the first Gatekeeper check when the Mac cannot fetch the ticket from Apple’s servers, such as when the machine is offline or the online ticket lookup is unavailable. In that case, a non-stapled app is more likely to be blocked or show a warning, which is why Apple says stapling is strongly recommended.
```

### Last known good version (optional)

```shell

```