Universal (Apple Silicon + Intel) build without Xcode

[trackme518]

Added support for macOS Apple Silicon (arm64), while remaining compatible with Intel macOS

The shipped native_libs binaries are x86_64-only, so they fail to load in arm64 JVMs (e.g. Processing 4 on Apple Silicon). Compiling with the current Xcode project is also impossible on modern macOS: Apple removed the JavaVM / JavaNativeFoundation frameworks and their headers from the SDK.

Changes

• JSyphon/native_src/build_universal.sh – new script that builds Syphon and libJSyphon.jnilib as universal (x86_64 + arm64) binaries using only the Command Line Tools and a JDK (for jni.h) — no Xcode required. Results are ad-hoc code signed.
• JSyphon/native_src/jnf/ – vendored JavaNativeFoundation sources (from apple/openjdk, xcodejdk14-release, APSL 2.0), compiled statically into libJSyphon.jnilib to replace the removed system framework.
• JNI sources – replaced removed <JavaVM/JavaVM.h> / <JavaVM/jni.h> imports with <jni.h>.
• Syphon built with -DSYPHON_CORE_RESTORE – the upstream state-restore code paths were never enabled in the Xcode build. Without them, Apple's OpenGL driver (which shares VAO/FBO/VBO bindings across share-group contexts) corrupts the host app's GL state when publishing frames from a core-profile context. This caused RuntimeException: Cannot validate shader program: Validation Failed: No vertex array object bound. in Processing P3D. tests/vao_test.m is a regression test for it.
• Syphon-Framework submodule bumped c404f3c (v5) → f476167 (post-5.0 tip of main, +99 commits): ARC conversion, modern atomics, Explicitly set pixel format type to 32BGRA and other Apple-Silicon-relevant fixes, Metal server/client support.
• Rebuilt build products: jsyphon.jar (unchanged bytecode, Java 8 target) and universal native_libs/{Syphon,libJSyphon.jnilib}.

Verification

• lipo -info shows x86_64 arm64 for both native binaries; both are code-signed.
• Tested on macOS 26 (Tahoe): JNI load, JSyphonServerList, server publish and client receive verified on arm64, and on x86_64 via Rosetta (vao_test.m passes on both: host VAO binding preserved, no GL errors).
• Used with Processing 4.5.6 (SendFrames, ReceiveFrames, SendScreen examples).

[trackme518]

Update: GL state restore fix (a5ad314)

The universal build worked on Apple Silicon, but any draw on the Processing context after publishFrameTexture rendered with corrupted vertex state (flat color / wrong size). Cause: macOS' GL-over-Metal shares some per-context state (active texture unit, blend, VAO/FBO bindings) between contexts in a share group, and the server's internal quad draw clobbers it.

This commit:

• jsyphon_JSyphonServer.m – captures the caller's GL state (active texture unit, 2D/rectangle bindings on units 0–3, VAO, read/draw FBO, renderbuffer, array/element buffers, viewport, scissor, blend, current program) before publishFrameTexture and re-applies it after. Element-array binding is rebound after the VAO since it lives inside the VAO. Pure state get/set – no texture copies, no sync stalls, ~40 driver calls per frame.
• Rebuilt native_libs/Syphon includes the renderer-side completion of the same fix (SYPHON_CORE_RESTORE: preserve state changed by drawFrameTexture Syphon-Framework#107): drawFrameTexture under SYPHON_CORE_RESTORE now also saves/restores the active texture unit, unit-0 texture bindings, viewport and blend — and fixes a latent bug where the previous texture binding was queried on the wrong unit. Until that PR merges, the prebuilt binary here is built against the patch (java/JSyphon/native_src/build_universal.sh).

Verified: minimal repro (offscreen P2D published once, then image() to main canvas) renders pixel-correct on arm64 and x86_64, P2D and P3D main renderers.