By: ValentinHirschi <valentin.hirschi@gmail.com>
verify both symbolica reproducers against official main The full unchanged GL262 builder input reproduces the same panic on official main ba3737137c2a2ccd7bb39f0441837d38ec867e78. Preserve a standalone loader adapting the new default inlining field with exact certificates, matching GL00 control, and final corrected-license receipts. The unchanged nonsymmetric import test passes upstream. Record the 32-bit product-length hypothesis and portable complete-input bundle. Validation: standalone fmt/check/build/clippy pass; GL00 operation counts match; fresh-process import write/read pass; GL262 independently reproduces the original panic with H1/CPE5, one core and 500 GB guard, without generated evaluator compilation. User request: Do you have a standalone Symbolica reproducer? In a folder, as a rust-script? Because it'd be nice to see if it also fails in the latest version of symbolic, i.e. current `main` branch (and not our fork). Also test the `import_remap.rs` there (this problem should be gone). This new symbolica version requires a new license key. The user subsequently supplied a corrected S-format key; license values are omitted from versioned artifacts. Actual upstream environment variable is SYMBOLICA_LICENSE.