* fix(ghidra): fail doctor when the JVM os.arch selects an unvalidated decompiler directory
probeJava now also reads the JVM os.arch property. When it maps to a
different native decompiler directory than the one validated from the
host architecture (for example an x86_64 JDK under Rosetta on Apple
silicon selecting os/mac_x86_64 while only mac_arm_64 was built), the
native_decompiler check fails with a remediation pointing at a
matching-arch JDK instead of reporting a healthy installation that
fails every analysis. Unknown os.arch values keep the previous
behavior.
* fix(ghidra): tighten JVM arch remediation and cover os.arch extraction
Address review findings on the JVM os.arch decompiler-directory check:
- The remediation no longer suggests building the decompiler for the
JVM-selected directory, which could never clear the check; it only
advises pointing JAVA_HOME at a matching-architecture JDK.
- Add a test running the real Java probe against captured
-XshowSettings:properties output, asserting os.arch reaches the
installation diagnostics.
- Document the JDK-architecture prerequisite in the Ghidra setup guide.
* fix(ghidra): refuse unrecognized JVM native architectures
* docs(ghidra): align doctor prerequisites with JVM architecture admission
* fix(ghidra): reject unreported JVM architecture
* test(ghidra): separate JVM and executable admission cases
* fix(ghidra): defer decompiler arch validation when Java is absent
* fix(ghidra): reject JVM native architecture override
* fix(ghidra): validate JVM platform overrides
* fix(ghidra): validate JVM os.name and helper-environment platform overrides
* test(ci): isolate report fixtures and declare PowerPC Java bounds
* test(ghidra): provide observed JVM platform in PowerPC fixture
* fix(ghidra): parse quoted JVM environment options before admission
---------
Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>
