Notarize macOS release builds to fix arm64 ICC/CMS import failure

[thetalkingdrum]

Problem

On unnotarized, ad-hoc-signed arm64 builds, imagecodecs's lazy dlopen of _cms.abi3.so is refused by AMFI (Error Domain=AppleMobileFileIntegrityError Code=-423 "The file is adhoc signed or signed by an unknown certificate chain"). This breaks color management for Flat/Print exports with Narrowband Scan or a custom ICC profile on Apple Silicon Macs (works fine on Intel).

Root cause confirmed on real M1 Pro hardware — see NARROWBAND_ICC_ARM64_INVESTIGATION.md on fix/narrowband-flat-export-icc for the full investigation, including:

• Reproduction steps and log evidence tying the AMFI denial to the exact moment of failure
• Why this never surfaces in dev mode (make run) — only in the packaged .app
• A tested-and-ruled-out free workaround (com.apple.security.cs.disable-library-validation entitlement doesn't help — wrong gate)

That branch already ships a workaround (falls back to a LUT-based ICC transform instead of silently skipping color management), so this is not launch-blocking. This issue tracks the durable fix.

Fix

Notarize the release build:

• Apple Developer ID Application certificate (requires paid Apple Developer Program membership, $99/year)
• notarytool submit --wait + stapler staple, wired into .github/workflows/release.yml
• CI secrets for the certificate/notarization credentials

Once this lands, the LUT fallback becomes unnecessary (or can stay as a defensive fallback) and NARROWBAND_ICC_ARM64_INVESTIGATION.md can be deleted.

Cost/lift

Requires a paid Apple Developer Program membership plus CI secret management — bigger lift than a code fix, hence tracked separately rather than blocking fix/narrowband-flat-export-icc.

[thetalkingdrum]

Closing — the root cause diagnosis behind this issue was wrong, so notarization isn't the fix here.

Re-investigated on real M1 hardware after external review challenged the AMFI theory (the AMFI log lines it was based on turned out to be routine noise logged for every ad-hoc-signed file, including ones that obviously loaded fine — the main NegPy executable and libpython3.13.dylib got the identical log line).

Actual root cause: cv2, PIL, rawpy, and imagecodecs each vendor their own liblcms2.2.dylib. PyInstaller collapses same-named dylibs from --collect-all into one canonical Contents/Frameworks/liblcms2.2.dylib, and it picked rawpy's copy — which is missing a symbol imagecodecs's _cms.abi3.so needs (_cmsChannelsOfColorSpace). imagecodecs's lazy import wrapper swallows the real dlopen error and re-raises a generic ImportError, which is why it looked identical to a codec-unavailable/signing problem.

Fixed in build.py on fix/narrowband-flat-export-icc (repoints the canonical symlink at imagecodecs' own copy) — no notarization or paid Developer account needed for this bug. Full writeup: LIBLCMS2_DYLIB_COLLISION.md on that branch.

Notarization may still be worth doing someday for the general Gatekeeper/quarantine download experience, but that's a separate, unevidenced motivation — feel free to open a fresh issue for it if it's wanted, scoped to that rationale rather than this bug.