chore: Perf/wheel pipeline and runtime defaults

[goodroot]

Some tidy around setup and process, as well as some performance improvements and defaults.

[github-actions]

Continue PR Review

Automated review via Continue CLI run through opub.

Summary

The PR is generally sound, but it introduces one likely packaging/install regression for CPU installs and one workflow gap that can let broken release wheels ship despite the new verification job.

Findings

• install_pywhispercpp_cpu() now verifies installation with import pywhispercpp immediately after pip install (lib/src/backend_installer.py). That import can fail even when the package was installed correctly if pywhispercpp imports optional/native runtime dependencies at import time. This changes success criteria from “package installed” to “package fully importable in this CI/runtime environment,” which is stricter than before and can cause false-negative setup failures for CPU users. Consider verifying with pip show pywhispercpp / metadata inspection, or importing a lighter module if available.
• The release workflow no longer validates the exact wheel artifact that users download from GitHub. In verify-wheels, the job copies dist/${EXPECTED_WHEEL} to a pip-compatible filename and installs the renamed file, but it never checks that the original +cuda12 wheel itself is accepted by pip or that the release asset name is usable as published (.github/workflows/build-wheels.yml). Since download_pywhispercpp_wheel() depends on downloading the suffixed asset and renaming it locally, a filename/packaging mismatch could still break end users while CI stays green. Add a test that downloads/installs the artifact exactly as published, then performs the local rename path used by backend_installer.py.

Suggested follow-ups

• Add a unit test for install_pywhispercpp_cpu() covering the “pip succeeds but import fails” path, to confirm the intended behavior and avoid accidental regressions.
• Add a test for _detect_venv_python_version() where python --version writes to stderr, since that was one of the behavior changes in this PR.

Summary

The diff is generally solid, but there are a couple of merge-blocking regressions around configuration defaults and wheel-install coverage that should be addressed before release.

Findings

• threads is now implicitly enabled for all users instead of being optional/auto-only. In lib/src/config_manager.py, the default config now sets 'threads': min(8, os.cpu_count() or 4), while the docs/schema say users should omit threads for auto behavior. This changes persisted config semantics: any code that distinguishes “unset” from “user explicitly set a value” will now always see a concrete integer. That can break existing auto-tuning/reload behavior and makes the documentation inaccurate. Either keep threads absent/None by default and resolve auto at use time, or update all consumers/schema/docs consistently.
• CPU installation path no longer has test coverage for the new --only-binary=pywhispercpp behavior and import verification. install_pywhispercpp_cpu() was materially changed in lib/src/backend_installer.py to stop using self-hosted wheels, require binary wheels from PyPI, and fail if import pywhispercpp does not work after pip succeeds. Those are good changes, but the added tests only cover helper functions and config defaults. Missing tests here create release risk for a user-facing install path, especially across Python 3.13/3.14 and filtered requirements scenarios.

Suggested follow-ups

• Add/adjust tests for install_pywhispercpp_cpu() covering:
  • successful install with --only-binary=pywhispercpp
  • pip success but import pywhispercpp failure
  • requirements filtering when PyGObject is skipped
• Reconcile threads behavior across config_manager.py, share/config.schema.json, and docs:
  • either restore “unset means auto” in code
  • or document/schema it as an always-materialized default and verify consumers handle that correctly

[goodroot]

Cool, yep, the rest is noise.