fix(tts): piper lazy-install parity + probe install-safety + null-config guards

[andrexibiza]

Related #44001 #44010 #47318 #61799 #77040 #77932

What changed and why

This PR completes the provider registry & lazy-install consistency bug class: built-in providers must be lazy-installable on fresh installs, requirements probes must never trigger pip installs, and provider fallback/readiness reporting must be truthful. It salvages and completes two open PRs (authorship preserved, see credits) plus the remaining null-config gap.

1. Piper TTS is now lazy-installable (issue #44001)

• tools/lazy_deps.py: added the missing tts.piper feature entry (was absent — fresh installs with tts.provider: piper failed with a manual-install error while edge/elevenlabs/mistral auto-installed).
• tools/tts_tool.py::_import_piper: calls lazy_deps.ensure("tts.piper") before importing, matching the Edge/ElevenLabs/Mistral pattern.
• Pin parity (maintainer-flagged gap in fix(tts): add piper-tts to lazy-install registry (#44001) #44010): piper-tts==1.4.2 is now pinned in all three places — the new [piper] extra in pyproject.toml, the tts.piper lazy entry, and the hermes tools post-setup installer (previously unpinned -U piper-tts, which could install a newer version and then get downgraded by the lazy pin on first use). uv.lock regenerated (adds piper-tts + pathvalidate).
• tests/test_project_metadata.py: [piper] added to the lazy-covered-extras contract so it can't leak into [all].
• tests/tools/test_piper_lazy_install.py: environment-independent (mocks find_spec instead of assuming piper is absent) and asserts the lazy pin matches the pyproject extra.

2. Requirements probes never lazy-install (follow-up to #77040)

• tools/transcription_tools.py::_get_provider: new install: bool = True kwarg; probe callers pass install=False so a bare status check can never freeze on a pip install.
• tools/voice_mode.py::check_voice_requirements and tools/wake_word.py::_stt_ready call it with install=False.
• Activation gate preserved (maintainer-flagged gap in fix(stt): keep requirements probes from lazy-installing faster-whisper #77040): an explicit uninstalled local STT provider now counts as ready when lazy installs are permitted — so classic /voice on still activates and the install happens at first real transcription, instead of rejecting an installable provider before the transcription path could install it. The probe itself never runs pip (regression test asserts install=False is passed).
• local_command exception removed (maintainer-flagged gap): the wake probe previously treated explicit local_command as ready whenever lazy installs were allowed, but the resolver never lazy-installs faster-whisper for local_command — arming the wake word on it would be unbacked. The readiness exception is now restricted to local only, with a regression test.

3. Null-config crash-proofing parity (issue #47318)

• tools/tts_tool.py::_generate_kittentts: the kittentts subsection read was the last TTS provider section not null-coalesced (tts.kittentts: null in config.yaml would yield None). Now uses the (x or {}) pattern already applied everywhere else on main (the core local: null / edge: null in config.yaml crashes STT/TTS with 'NoneType' object has no attribute 'get' #47318 fix landed earlier via fix(stt/tts): null provider subsections no longer crash voice tools (#47318) #61799; this closes the remaining site).

How to test

# Targeted suites (venv python from the main checkout):
python -m pytest tests/agent/test_tts_registry.py \
  tests/hermes_cli/test_plugins_tts_registration.py \
  tests/tools/test_tts_container_repair.py \
  tests/tools/test_piper_lazy_install.py \
  tests/tools/test_wake_word.py tests/tools/test_voice_mode.py \
  tests/test_packaging_metadata.py tests/test_project_metadata.py \
  -q --no-header -p no:cacheprovider
# → 140 passed (6 deselected = pre-existing Windows env failures, identical on main)

Behavioral probes run during development:

• Piper registry parity: tools.lazy_deps.LAZY_DEPS["tts.piper"] exists; _import_piper() calls ensure("tts.piper", prompt=False).
• Probe has no install side effect: _get_provider({"enabled": True, "provider": "local", ...}, install=False) makes 0 calls to _try_lazy_install_stt, while install=True makes exactly 1.
• Unknown provider reports truthfully (already merged via fix(tts): report unknown-provider fallback truthfully #77932, verified against this branch): provider: "edge" + fallback_from: "missing-provider" instead of masquerading as the unknown name.
• Null config: config.yaml with stt.local: null / tts.edge: null / tts.kittentts: null loads and both TTS generation and STT provider resolution complete without 'NoneType' object has no attribute 'get'.

Platforms tested

• Windows 10 (git-bash), CPython 3.11 — full targeted suites + behavioral probes.
• git diff origin/main --check clean; scripts/check-windows-footguns.py clean on all touched files (only pre-existing WSL-gated test line flagged, not touched by this PR).

Why this matters to users

• Fresh installs can pick Piper TTS without manual pip install piper-tts — it now auto-installs on first use like every other built-in provider, at a version consistent with hermes tools (no surprise downgrades).
• /voice on, wake.status, and TUI status polls never hang on pip installs — but an installable local STT provider still activates correctly and installs at first transcription.
• Null provider sections in config.yaml (which setup flows can produce) no longer crash STT/TTS.
• Config still wins: unknown provider names fall back to Edge but the tool result says so truthfully (fallback_from), so agents/users aren't silently misled about which engine produced the audio.

Fixes #44001

Credits

• Salvaged from fix(tts): add piper-tts to lazy-install registry (#44001) #44010 (piper lazy-install registry), authored by @liuhao1024 — commit fdccbd6431.
• Salvaged from fix(stt): keep requirements probes from lazy-installing faster-whisper #77040 (probe install-safety), authored by @Limkyy — commit f576f7b907.
• Completion work (pin parity, pyproject [piper] extra + lockfile, activation-gate preservation, local_command exception removal, null-coalesce for kittentts, tests) by @andrexibiza — commit e35c25ff69.
• local: null / edge: null in config.yaml crashes STT/TTS with 'NoneType' object has no attribute 'get' #47318 was fixed on main earlier via fix(stt/tts): null provider subsections no longer crash voice tools (#47318) #61799; this PR closes the one remaining unguarded subsection read and adds regression coverage.

Part of #65160
Part of #78207
Part of #79890

[andrexibiza]

CI on this PR failed on tests/tools/test_transcription_tools.py::TestRunCommandSttIdleTimeout::test_stderr_progress_extends_beyond_timeout (tests slice 3/8). Verified: pre-existing broken timing test, not a change from this PR.

Evidence:

• This PR's diff on tools/transcription_tools.py only adds the install=False probe guard to _get_provider — it never touches _run_command_stt or this test (confirmed by diff inspection).
• The test fails identically on a pristine origin/main worktree (942ff91f21) on Windows.
• Probe of the failure mechanism: the child emitted all four ticks + done, yet the runner still raised TimeoutExpired at transcription_tools.py:785 — the 0.1s idle window is shorter than Windows process spawn latency, so the first stderr chunk can never arrive inside the window. On Linux CI it only flakes under 8-worker load; sibling PRs fix(voice): resolve Porcupine wake-word key through the credential resolver #78191 and fix(gateway): serialize STT/TTS reliability slice behind V6 contract #78196 passed the same slice 3/8.
• GitHub refused a re-run of the failed job ("workflow file may be broken"), so the evidence above is the receipt.

Fix: the test is stabilized in #78221 (immediate first tick, 250ms idle window, 5× tick period — pass still depends on the progress extension). Once #78221 merges and this branch picks up main, this slice should go green. No code change needed on this PR.

[andrexibiza]

Checks on this PR were red on test_stderr_progress_extends_beyond_timeout (tests slice 3/8) — the pre-existing timing flake documented in my earlier comment on this PR. The fix lives on #78221 (test stabilization: immediate first tick, 250ms idle window, 5× tick period); rather than wait for the merge chain, the fix commit is now cherry-picked directly onto this branch at 758ffa3b93.

Verification on the new head (3 consecutive local runs): TestRunCommandSttIdleTimeout → 2 passed each run; git diff --check clean. CI is re-running on 758ffa3b93.

Note for merge ordering: the same test fix exists on #78221 — when both merge, git will dedupe (identical change); either merge order is fine.

[andrexibiza]

The re-run after the 758ffa3b93 cherry-pick is green on the previously-failing slice 3/8 (the timing test fix landed), but surfaced a different failure in slice 8/8: tests/agent/test_compression_worker_isolation_76354.py::test_f3_mutating_engine_cannot_touch_live_transcript_after_timeout (line 111, live == baseline).

This is a sporadic load-timing flake, not a change from this PR:

• The failing test is in tests/agent/ (compression-worker isolation); this PR's diff touches tools/transcription_tools.py, tools/tts_tool.py, tools/voice_mode.py, tools/wake_word.py, tools/lazy_deps.py, hermes_cli/tools_config.py and their tests — no shared code.
• Slice 8/8 passed on this branch's previous head (e35c25ff69): the only delta is the test_transcription_tools.py commit, which this test never imports.
• Slice 8/8 also passed on sibling PRs with the same base (test(stt): stabilize idle-timeout progress test against spawn latency (pre-existing flake on Windows + loaded CI) #78221, the series merges).
• The test asserts isolation while the mutating engine thread is still running (event-driven, host-timeout race) — inherently scheduling-sensitive under the hermetic 8-worker slice.
• Passes 3/3 locally on this head (5–8s runs).
• GitHub refused an API re-run of the job ("workflow file may be broken" — same refusal seen on other PRs' runs), so the next push/merge of main re-triggers CI.

Treating this as evidence-documented and separate from the PR's scope; the compression-isolation test hardening would be its own change if it keeps flaking.