plugins/bithuman: let a session name the second-generation models - #7366

`AvatarSession(model=...)` accepted only "expression" and "essence", and the
request it sent named no model at all — just `mode: gpu|cpu`, which can
distinguish exactly two engines. Which model a second-generation avatar was
served as therefore depended on a server-side default rather than on what the
caller asked for, and the caller had no way to say.

Measured against BitHuman's live API with one account, on an avatar prepared for
only one model (`supported_models: ["expression-1"]`), the payload built by this
plugin's own `_send_json_request`:

  1.8.2   model="essence"       sends no model, mode=cpu
          -> HTTP 200, session STARTED and served as expression-1

A session started as a model the caller did not ask for, and nothing said so.

  this    model="expression-2"  sends model="expression-2", mode=gpu
          -> HTTP 409, "agent ...'s expression-2 model hasn't been generated
             yet - add it with POST /v1/agent/{code}/models ..., then retry"

...before a renderer launches or a credit is spent. On an avatar that IS
prepared, the same call is answered `{"model": "expression-2",
"avatar_session_started": true}` where 1.8.2 was answered "expression-1".

  model="essence-2" reaches the Essence 2 launcher, which names the bundle it
  wants for that identity - so the string routes end to end.

The two first-generation names are unchanged and keep resolving to the
first-generation engines: driven against the same API, "expression" and
"essence" produce byte-identical payloads to 1.8.2 apart from the added field,
and the same responses.

`mode` is still sent, unchanged, for servers that predate `model`; the server
prefers the explicit field. The gpu/cpu split and the custom-endpoint request
format now read one property, `_is_expression_model`, so the two sites cannot
disagree about which family a session is - dispatching one way and billing the
other is the failure that shape invites.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012vTGmNLyJSwj28bfFk5gG2

Devin review, and it is right: `NotGivenOr[BitHumanModel] = "essence"` lets a
caller pass NOT_GIVEN explicitly, and code forwarding an optional parameter does
that routinely. NotGiven defines `__repr__` as "NOT_GIVEN" and no `__str__`, so
`str(NOT_GIVEN)` is the literal string "NOT_GIVEN" (measured against the real
class in livekit/agents/types.py, not assumed). It would have been sent as the
model name and refused by the server, on a call the caller meant as "the
default".

Fixed at the ASSIGNMENT rather than at the reported read site, because there are
two readers and the reported one is not the only one at risk:

  self._model = model                              # __init__
  str(self._model).startswith("expression")        # _is_expression_model
  "model": str(self._model)                        # the session request

With NOT_GIVEN the second yields False and the session is dispatched "cpu". That
happens to agree with the essence default, so it is benign today — purely by
luck, and that property's own docstring says the two readers "must give the same
answer in both, or a session is dispatched one way and billed the other".
Patching only the JSON field would have left that agreement resting on a
coincidence. Normalising once makes both correct by construction.

Verified across every input the signature admits — NOT_GIVEN, essence,
essence-2, expression, expression-2 — that the model sent is always one of the
four valid names and that the dispatch mode matches it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0134RFpn6JSLqWYJ88rJ9ohB

CI type-check, both 3.10 and 3.13:

    "AvatarSession" has no attribute "_model"; maybe "_mode"?   x5

The previous commit rewrote the block that assigns `self._model` in order to
replace the explanation above it. The replacement kept the comment and dropped
the line it was explaining, so `self._model` was never assigned at all — an
AttributeError on the first session, not merely a typing complaint.

Two things did not catch it, and both are worth naming. My local mypy run could
not resolve the base class in this environment, so the attribute error was
invisible among ten pre-existing import-resolution errors that are identical
before and after the change. And the behaviour matrix I ran to "prove"
equivalence modelled the LOGIC in a separate script rather than exercising the
module — so it happily proved a property of code that was no longer there. CI,
which installs the package properly, found it in one run.

Added a structural check while fixing it: every `self._X` that is read must also
be assigned somewhere in the class. It reports `_model` missing on the broken
version and clean on this one (`_room` is inherited and shows in the green
control too, so it is not a new finding).

Behaviour is unchanged from the intent of the previous commit: `model` defaults
to NOT_GIVEN and is sent only when the caller names one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0134RFpn6JSLqWYJ88rJ9ohB