Add native, arm64-python interpretor for Hermes on WoA

[ORippler]

What does this PR do?

Replaces x64-based emulation with native arm64-based Hermes (by virtue of being a python package and changing the interpretor). Arm64-native builds will give better performance compared to emulated counterparts.

Related Issue

Fixes #95569

Type of Change

• 🚀 Performance improvement (native is better than emulated)
• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

Concrete changes made to install.ps1

1. Explicitly install2 python aarch64 on windows-on-arm systems in uv. This is favored over setting UV_PYTHON=arm64 to make it isolated to hermes: uv installs x86_64 Python on arm64 Windows  astral-sh/uv#12906 (comment)
2. cryptography needs to be build from scratch (no arm64-packages for WoA published since 46.0.3). cryptography requires OPENSLL, and thus this needs to be installed. I didn't investigate if there is a slimmer alternative available than installing from https://slproweb.com/products/Win32OpenSSL.html

Not sure if/how these will translate to good dev UX, but end-users should be fine

How to Test

1. Execute install.ps1 on WoA system
2. Inspect python.exe when invoking hermes

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Windows 11 Arm64

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

[Enough1122]

AI code review — automated review for reference; please use your judgment.

Add native, arm64-python interpreter for Hermes on WoA — substantial, careful installer work. Three coherent pieces: uv -aarch64 preference with fallbacks (qualified-first find, venv retry on qualified failure → x64 with an emulation warning), Install-WoaOpenSsl to let cryptography 50.x build from source on win_arm64, and arch detection wired after function registration. The qualified-then-fallback pattern is consistently applied and the $venvExitCode -ne 0 -and $venvPythonRequest -ne $PythonVersion retry net is a good safety valve.

Main notes (non-blocking):

1. Supply-chain maintenance: Install-WoaOpenSsl downloads a ~220 MB third-party MSI (slproweb.com) and installs it with a pinned SHA256 — good hygiene (deterministic, verified). But pinning a specific version (3_6_4) means (a) the pin must be re-verified against the vendor's release page on every bump, and (b) the install fires a large download whenever WoA has no OpenSSL laid out, even before it's known the source build will be triggered. A comment pointing at how the hash was obtained + when to refresh it (and ideally a -SkipWoAOpenSSL escape hatch) would reduce future-maintainer friction. The Write-Warn on mismatch is correct (refuses to install).

2. Naming/side-effect: Test-NativeArm64PythonAvailable installs an interpreter when none is found. The name implies a pure predicate; the side effect is documented and the find-first makes the common case cheap, but a name like Ensure-NativeArm64Python would set the right expectation.

3. Install-WoaOpenSsl scope: it runs unconditionally inside Install-Dependencies for arm64 hosts. The early-return when OPENSSL_DIR/an existing layout is found mitigates the common case, but a user who has no OpenSSL and doesn't need cryptography source builds (e.g. only wants an interpreter fix) still pulls the ~220 MB. Acceptable, but worth noting the check-first structure is what keeps this bounded.

4. No automated tests (installer PS1 isn't in the test harness) — the logic is intricate enough (arch preference matrix, venv retry, MSI install + path discovery) that a manual WoA validation pass with both uv python find cache states (empty vs primed) is warranted before merge.

The arch-detection scoping comment (functions must be registered before the call) and the emulation warning surfaced after venv creation are thoughtful touches. Approve.