bithuman: type-check against bithuman 2.11

[longcw]

Problem: uv.lock pins bithuman 2.9.0, whose stub declares AsyncBithuman: Any, so every call through the runtime is unchecked. Version 2.11.0 ships real types, so the next resolve fails make check with eight errors in avatar.py.

Fix: The call to AsyncBithuman.create passes its arguments directly, so 2.11 can check them, and __init__ normalizes _runtime to one absent value, which closes a hole in the runtime property. uv.lock moves to 2.11.0, which the two removed type: ignore comments require.

Follows #7280.

Context for reviewing and coding agents

How to see it

Run uv lock --upgrade-package bithuman, then uv sync --all-extras --dev, then uv run --group typing python scripts/check_types.py.
On main this reports eight errors in avatar.py: five on the create call, one return-type error on the runtime property, and two unused type: ignore comments.

Why the lock bump cannot be a separate PR

bithuman 2.9.0 stubs AsyncBithuman as Any, so settings.FPS is Any and warn_return_any requires the type: ignore. 2.11.0 types the field, so warn_unused_ignores rejects the same comment.
The two states are mutually exclusive, and CI installs from the lock, so the code fix alone would fail.
bithuman 2.9.0 is also delisted from PyPI, so no resolve can select it again. The current lock installs only because the pinned wheel URL still resolves.

The runtime property returned NOT_GIVEN

The runtime parameter is declared NotGivenOr[AsyncBithuman | None], and the property tested is None only, so the default path returned the sentinel instead of raising BitHumanException.
Callers then failed with AttributeError on a NotGiven object. Cloud mode never assigns _runtime, so every read of .runtime there hit this.

The direct create call does not change behavior

The dropped if self._api_secret: and if self._api_token: guards are equivalent to passing None, because bithuman resolves api_secret or os.environ.get("BITHUMAN_API_SECRET", "") and ignores token in 2.11.
bithuman 1.5.0, which Windows, x86_64 macOS and macOS < 14 resolve to, declares the same four parameters with the same None defaults, so the fallback path is unaffected.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.