Harden macOS code signing and notarization

[Marc-André Moreau (mamoreau-devolutions)]

Root cause

The repeated production failures were caused by invalid bundle layout, not just signing order. The NativeAOT publish left dt.runtimeconfig.json in Contents/MacOS; Developer ID bundle signing treats regular files there as nested code and rejects the JSON sidecar. Earlier fixes moved notice files and skipped the main executable, but did not remove the remaining non-code file.

The next latent failure was also addressed: notarytool accepts archives and disk images, not a raw .app directory.

Changes

• remove NativeAOT runtime-config sidecars from the staged app and reject future non-Mach-O files in Contents/MacOS
• add a macOS regression test that reproduces the original In subcomponent: ...runtimeconfig.json failure and verifies the corrected bundle
• sign auxiliary Mach-O files in isolation while preserving their identifiers
• verify every signature's Team ID, secure timestamp, and Hardened Runtime metadata
• submit app bundles for notarization through temporary ZIPs, require an Accepted response, staple tickets, and verify Gatekeeper acceptance for both apps and DMGs
• resolve the imported Developer ID identity instead of relying on a hard-coded display name, fail real signing runs on missing secrets, and clean up the temporary keychain

Validation

A production-environment signed dry run completed successfully end to end: https://github.com/Devolutions/devolutions-terminal/actions/runs/35164984505

• both osx-arm64 and osx-x64 app submissions: Accepted, stapled, source=Notarized Developer ID
• both signed DMG submissions: Accepted, stapled, source=Notarized Developer ID
• macOS package validation passed for both architectures
• all build, test, packaging, signing, and final dry-run release-staging jobs passed
• final release artifact uploaded successfully