[ero-qt]

Part of #154.

Keys the Linux Mono builds on the first patch of each layout, the same way #175 did for Windows. Linux Mono ships without symbols, so I pulled the Mono libraries of each patch out of its Linux Build Support package and booted them to measure where the structs sit. I searched every minor from 5.6 to 6000.6 that way, and the layouts change at the exact same patches as on Windows:

• libmono.so at 5.6.0, 2017.4.6, 2018.1.0 and 2018.1.7. Like mono.dll, it goes back to the 5.6.0 layout from 2018.1.0 to 2018.1.6.
• libmonobdwgc-2.0.so at 2017.1.0, 2017.2.0 and 2021.2.0. Like mono-2.0-bdwgc.dll, 2017.1 has an older layout without class_kind, but its offsets aren't the same as on Windows.

The offsets of the entries that were already there don't change, since the measurements matched them. Before this, a 2021.2.0 player got the 2017.3 offsets and a 2017.4.6 player got the 5.6.7 offsets.

The Linux profile constants get the new versions in their names, for example UNITY_5_6_0F1_LINUX_MONO_X86_64.

[CryZe]

The first-layout version boundaries and the public constant renames look good. I found one runtime regression in the exact-build-ID lookup that should be fixed before merging; details and real fixture-package evidence are in the inline comment. This is not a request for source compatibility or deprecated public constants: preserving the old identities privately is sufficient.

[CryZe]

The original runtime concern is addressed by the agreed API policy: both automatic Mono attachment methods require alloc, so executable-based version detection is fully available and unsupported no-alloc calls fail at compile time. Explicit-profile attachment remains available without alloc on Windows/Linux. This intentionally supersedes the earlier requests for retained ID aliases or a no-alloc lookup prerequisite for #190. The first-layout boundaries and renamed public profile constants remain as reviewed.

Verified the public feature boundary with compile probes, the older Linux executable fallback with synthetic process memory based on the real fixture deployment, 255 all-feature unit tests, 240 no-alloc Unity tests, 83 release Mono tests, and 24 doctests. Both SIMD release WASM targets build with and without alloc. Lunistice's release build remains 40,755 bytes. All seven fresh GitHub checks pass for this exact head. No real Linux player was executed during this review.

[ero-qt]

Hey, I checked this PR against 45 real Linux Mono players, 37 versions from 5.0.0f4 up to 6000.6.0f1. Mono reads every value correctly on all of them. All 7 entries in the table matched their player by build id, and the players whose build id isn't in the table used the executable's version, like 5.6.7f1 taking the 5.6.0 build. The only failures were scene values, since Linux scenes come with #189. Thanks for sorting out the alloc part.

Versions

libmono.so: 5.0.0f4, 5.6.0f1, 5.6.2f1, 5.6.7f1, 2017.1.0f3, 2017.2.0f1, 2017.3.0f3, 2017.4.6f1, 2017.4.40f1, 2018.1.0f1, 2018.1.7f1, 2018.2.0f2, 2018.3.0f2

libmonobdwgc-2.0.so: 2017.1.0f1, 2017.1.0f3, 2017.2.0f1, 2017.3.0f1, 2017.3.0f3, 2017.4.6f1, 2017.4.40f1, 2018.1.0f1, 2018.2.0f1, 2018.2.0f2, 2018.3.0f1, 2018.3.0f2, 2019.1.0f1, 2019.1.0f2, 2019.3.0f1, 2020.2.0f1, 2021.1.0f1, 2021.2.0f1, 2021.2.20f1, 2022.2.0f1, 2022.3.5f1, 2023.1.0f1, 2023.1.4f1, 2023.2.0f1, 6000.0.59f2, 6000.1.0f1, 6000.2.0f1, 6000.2.2f1, 6000.3.0f1, 6000.5.0f1, 6000.5.10f1, 6000.6.0f1