6.19.4 - A demo bundle whose frameworks can be signed

Packaging only, and the release that actually produces a working demo .dmg. No library change: consumers pinning 6.19.2 or 6.19.3 get byte-identical engine code.

What 6.19.3 got wrong

6.19.3 embedded the nine FFmpeg frameworks the demo binary loads, which was the fix it set out to make, and then failed one step later:

Contents/Frameworks/Libavcodec.framework: replacing existing signature
Contents/Frameworks/Libavcodec.framework: Permission denied

The xcframework payloads are mode 555 and cp -R preserves permissions, so codesign could not replace the signature they already carry. The copies are now made writable before signing.

A guard that proved the wrong thing

The same run exposed a hole in the check 6.19.3 introduced. It verified that every @rpath dependency was present in Contents/Frameworks, and a bundle can satisfy that completely and still abort in dyld, because nothing points an rpath at that directory. Presence is not resolvability, and a check that conflates them passes exactly when the failure it was written for occurs.

It now fails first when the binary carries no @executable_path/../Frameworks rpath, then checks that each dependency resolves inside the bundle.

Verified through the whole chain including the negative control: the copy without the permission fix reproduces the CI error verbatim, and the copy with it signs, passes codesign --verify --strict --deep, and launches.

Dependencies

Unchanged from 6.19.2: FFmpegBuild 2.4.2, FFmpeg n8.1.2, four local patches.