fix(wake): pin sherpa-onnx to 1.12.40 — 1.13.x never fires on macOS arm64

[AnalogHubris]

fix(wake): pin sherpa-onnx to 1.12.40 — 1.13.x never fires on macOS arm64

sherpa-onnx 1.13.x is a broken wheel on macOS arm64: KeywordSpotter builds,
streams, and reports no error, but produces ZERO detections — even against
sherpa's own bundled model and test wavs. The wake listener "arms" (log shows
listening for the phrase) but the phrase never triggers. Verified locally on
2026-07-31 with a synthetic "hey robot" clip through the engine: 1.13.4 = no
detections, 1.12.40 = clean detection.

The pypinyin half of the sherpa runtime dep is already covered by #74733 /
#74768 / #75321; this PR only pins the broken wheel back to the last version
that actually fires, and adds the matching sherpa-onnx-core pin so the native
closure resolves (adjacent to #77947, which locks 1.13.4-core for a different
dlopen issue but does not fix detection).

• tools/lazy_deps.py: wake.sherpa 1.13.4 → 1.12.40 (+ core pin)
• pyproject.toml: wake extra same pins

Fixes the silent never-fires wake word on Apple Silicon.

[spfcraze]

This was generated by AI during triage.

Summary:
This PR pins sherpa-onnx==1.12.40 in pyproject.toml and tools/lazy_deps.py while the committed uv.lock still resolves 1.13.4, which fails the repo's pin/lock lockstep test and the hash-verified --locked install tier.

Problems:

• uv.lock:1916 still carries specifier = "==1.13.4" for the wake extra, so the lock and the new pins disagree on sherpa-onnx.
• tests/test_project_metadata.py:196 (test_every_lazy_deps_exact_pin_matches_uv_lock) requires every lazy_deps exact pin to match the locked version; running its logic against this PR's LAZY_DEPS and the committed uv.lock reports drift (lazy_pin 1.12.40, uv_lock 1.13.4), so the invariant test fails.
• scripts/install.sh:1581 installs via uv sync --extra all --locked; with pyproject.toml changed and the lock not regenerated, that tier fails (the comment at install.sh:1553 names exactly this out-of-sync case) and fresh installs fall back to the unverified PyPI-resolve tier.

Solution:
Regenerate uv.lock in the same commit (uv lock / uv lock --upgrade-package sherpa-onnx) so it resolves sherpa-onnx 1.12.40 and adds sherpa-onnx-core, per the lockstep contract at tests/test_project_metadata.py:208.

---

Checked against abb8d40 — the PR head when this was written — and 226b095, main at the same moment.

[DavidMetcalfe]

Nice catch — I independently reproduced the same A/B on an Apple Silicon Mac (macOS 26.5.2 arm64) and your pin is the right one. Details for the record:

Verification (same engine path as Hermes' _SherpaKwsEngine)

Fresh venvs with your exact pins, Hermes' call pattern (1280-sample frames @ 16 kHz, accept_waveform → is_ready → decode_stream → get_result, reset_stream on fire, BPE keywords file <tokens> @DISPLAY), the sherpa-onnx-kws-zipformer-gigaspeech-3.3M model's own bundled test wavs and keywords, threshold 0.25 (Hermes' default sensitivity):

• sherpa-onnx==1.13.4 + sherpa-onnx-core==1.13.4: 0 detections (both test wavs)
• sherpa-onnx==1.12.40 + sherpa-onnx-core==1.12.40: 3/3 detections (LIGHT_UP, LOVELY_CHILD, FOR_EVER)

Also confirmed on PyPI that sherpa-onnx==1.12.40's only requirement is sherpa-onnx-core==1.12.40 — no conflict with the onnxruntime==1.27.0 pin the wake extra already carries for openWakeWord, so the resolution is clean.

Blocker to merge: uv.lock must be regenerated in the same commit

The AI triage comment is right. With pyproject.toml/tools/lazy_deps.py at 1.12.40 and uv.lock still resolving 1.13.4:

• tests/test_project_metadata.py:196 (test_every_lazy_deps_exact_pin_matches_uv_lock) fails — the contract requires pin == locked version, with the lock regenerated in the same commit (uv lock --upgrade-package <name>)
• fresh installs via uv sync --extra all --locked (scripts/install.sh:1581) fail and fall back to the unverified resolve tier
• the CI lockfile check runs uv 0.9.28 (.github/workflows/uv-lockfile-check.yml:77), so regenerate with that exact version to avoid lockfile-format drift

Suggested command (after the pin edits, using uv 0.9.28):

uv lock --upgrade-package sherpa-onnx --upgrade-package sherpa-onnx-core

Two small suggestions

1. Reference the issue this fixes — hermes-agent#79026 ("wake word completely non-functional on macOS ARM64 — both engines fail") is currently unlinked, and its sherpa half is exactly what this PR fixes. Adding Closes #79026 to the description would cross-link them. It also relates to macOS arm64: Sherpa wake lock omits required core and reports false availability #77936 (missing sherpa-onnx-core in the lock — your 1.12.40-core pin resolves that closure cleanly on arm64).
2. Keep the pin global as-is. 1.13.4 is the latest release and we have no evidence KWS is broken on other platforms, but there's no critical 1.13.x fix worth keeping either, and a single pinned version is what the lockstep test is built around. If upstream later fixes the arm64 regression, bumping back is a one-line change.

Happy to re-test anything else if useful.

[AnalogHubris]

Lockfile regenerated in the same commit (uv lock --upgrade-package sherpa-onnx --upgrade-package sherpa-onnx-core), rebased onto current main.

• uv.lock now resolves sherpa-onnx==1.12.40 + sherpa-onnx-core==1.12.40
• test_every_lazy_deps_exact_pin_matches_uv_lock lockstep: 0 drift
• scripts/install.sh --locked path should now agree with the pins

Head: 6017dfb6a