Darwin: fix current macOS/Arm build and XPCOM runtime

[moreaki]

Summary

Make a current macOS/Arm source build work with the selected Apple SDK and Homebrew Qt 6, then keep its XPCOM management path usable with the current Clang ABI.

The pull request has four focused commits.

1. Configure and Qt layout

• pass the selected macOS SDK to Darwin compile probes with -isysroot;
• search the SDK C++ headers before Homebrew's fallback include/c++;
• treat an explicit Darwin --with-qt-path as a framework root;
• derive framework header and -F paths from QtCore.framework;
• detect Homebrew Qt tools in share/qt/libexec and plugins in share/qt/plugins.

2. Compiler-proven source blockers

• avoid redefining macOS 15 GIC types when the SDK already provides them, while retaining old-SDK fallbacks and dynamic runtime gating;
• use an unannotated local value for the dynamically supported ACTLR register;
• make the battery threshold float conversion explicit;
• cast Carbon hot-key Unicode constants to the Qt QChar storage type;
• brace the DNS server-address block, fixing the warning and preventing stale-value parsing for a null array entry.

3. XPCOM generic-factory output

With the clean build, VBoxManage --version worked but VBoxManage list vms reproducibly exited on SIGSEGV. Both VBoxManage and VBoxSVC crashed in nsGenericModule::GetClassObject at the factory QueryInterface call because the generated current-Clang code dereferenced a null smart pointer after the aliased output call.

Use a raw temporary only for the factory output, query it, and release it. This preserves the ownership transfer while removing the aliased smart-pointer output.

4. XPCOM IPC UTF-16 width

After the factory crash was removed, VBoxManage list vms returned a truncated name and UUID:

"Win" {d486670d-120b-40b6-}

The IPC wire format is UTF-16, but the legacy PRUnichar assumptions do not reliably remain two bytes in this current Darwin component build. Measure, allocate, terminate, and copy with IPRT's fixed-width RTUTF16 types while preserving the existing XPCOM-facing pointer type.

Scope

Every configure/source change corresponds to a clean-build compiler failure or an exact management-command runtime failure on macOS/Arm with SDK 26.5 and Qt 6.11.1. The Hypervisor availability handling remains compile-time-only; the macOS 15 APIs continue to be resolved and gated dynamically at runtime.

Non-Darwin configure behavior and Oracle/devtools Qt layouts are unchanged. The factory ownership sequence is semantically unchanged, and the IPC change makes the existing two-byte wire contract explicit.

Reproduction and validation

Configure:

./configure.py --disable-hardening \
  --with-kbuild-path=/path/to/kBuild \
  --with-macossdk-path=$(xcrun --sdk macosx --show-sdk-path) \
  --with-xcode-path=/Library/Developer/CommandLineTools \
  --with-qt-path=/opt/homebrew/opt/qt

Validated results:

• git diff --check and python3 -m py_compile configure.py pass.
• A clean configure succeeds with SDK 26.5 and Homebrew Qt 6.11.1.
• Generated Qt paths resolve the Homebrew tools/plugins, including libqcocoa.dylib.
• A full integrated kmk -j6 build passed for the configure/compiler changes.
• After the two XPCOM commits, kmk -j6 VBoxXPCOM VBoxXPCOMIPCC and the dependent VirtualBoxVM target pass.
• The staged arm64 app passes strict deep code-signature verification with the VM hypervisor/JIT entitlements retained.
• VBoxManage list vms exits 0 and returns the complete value:

"Win11" {d486670d-120b-40b6-8ef3-24ff3c14ef71}

• VBoxManage showvminfo Win11 --machinereadable also returns the full name/path and reports the expected vboxsvga, 3D-enabled, 256 MiB VRAM configuration.

Refs #742.

[oracle-contributor-agreement]

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

• PR author: moreaki
• rnibali@gmail.com (@moreaki)

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.