fix(stt): report unregistered configured providers

[ooiuuii]

Summary

• return a provider_not_registered STT error when an explicit stt.provider name is not claimed by a built-in, command provider, or plugin provider
• keep the generic No STT provider available guidance for auto-detect failures with no explicit provider
• update STT plugin dispatch coverage for both paths

Fixes #55167.

Why

This mirrors the diagnostic boundary fixed in openclaw/openclaw#97484: when the user configured a concrete media/STT provider id, the error should preserve that id and point at the registration surface instead of falling through to generic setup advice.

Before this change, stt.provider: openrouter with no matching plugin and no stt.providers.openrouter.command returned only the generic No STT provider available message. That made the missing registration look like a local/Groq/OpenAI setup problem.

Validation

• python -m pytest tests\tools\test_transcription_plugin_dispatch.py -q -> 29 passed
• ruff check tools\transcription_tools.py tests\tools\test_transcription_plugin_dispatch.py -> passed
• git diff --check -> passed
• python scripts\check-windows-footguns.py --diff origin/main -> passed

Additional adjacent check attempted:

• python -m pytest tests\gateway\test_stt_config.py tests\tools\test_transcription_plugin_dispatch.py -q -> 34 passed, 2 failed
• The two failures are pre-existing Windows path expectation mismatches in tests/gateway/test_stt_config.py: the tests assert /tmp/voice.ogg, while the Windows run returns C:\tmp\voice.ogg. They do not exercise the STT provider registration path changed here.

No repository-local autoreview helper was found; only standard scripts such as scripts/check-windows-footguns.py are present.

[teknium1]

Thanks for isolating the diagnostic boundary. Current main still falls through from unsuccessful plugin resolution to the generic envelope at tools/transcription_tools.py:1713-1751, so the reported configured-provider ambiguity is real.

Problems

• website/docs/user-guide/features/tts.md:581-586 currently documents every no-match as the generic No STT provider available result. This change makes an explicit unregistered stt.provider return provider_not_registered, so the documented resolution order needs the corresponding distinction.

Suggested changes

• Update the STT resolution-order documentation to describe the explicit-unregistered-provider envelope while retaining the generic auto-detect/no-provider outcome.

Automated hermes-sweeper review.

[teknium1]

Merged into main via consolidated salvage PR #73510 (merge c0c5dac531). Your named provider_not_registered error for configured-but-unregistered plugin providers was cherry-picked with your authorship.

Your contribution is credited to you in git history. Thank you! Closing this PR as merged-via-salvage.