…sion tests (NousResearch#29344)

SmelterLabs suspected a second-layer bug beyond the classifier fix (cc93053):
_swap_credential might update the credential pool entry but NOT propagate the
new token into the live OpenAI SDK client / HTTP transport, leaving the next
request on the stale token.

Full trace of the propagation chain for non-Anthropic providers (xai-oauth):

    _swap_credential(entry)
      → self._client_kwargs["api_key"]  = runtime_key     (run_agent.py:2910)
      → self._client_kwargs["base_url"] = runtime_base    (run_agent.py:2911)
      → self._replace_primary_openai_client(
            reason="credential_rotation")                 (run_agent.py:2913)
          → self.client = OpenAI(**self._client_kwargs)   (line ~2501)

On the next API call, _create_request_openai_client copies _client_kwargs
(line ~2574) into the fresh per-request client — the refreshed token flows
through automatically.  No propagation gap exists.

The stale-token issue reported in NousResearch#29344 was entirely at the classifier layer:
_is_entitlement_failure and the xai-oauth catch-all in
recover_with_credential_pool both misclassified bad-credentials 403s as
entitlement, blocking the refresh path before _swap_credential ever ran.
Commits cc93053 and b5ea6a5 fixed that layer.

This commit:

* Adds a detailed docstring to _swap_credential documenting the propagation
  chain and the NousResearch#29344 investigation conclusion.
* Adds 10 regression tests in test_xai_oauth_token_propagation.py that
  exercise the full path: stale token → 403 → recovery → _swap_credential
  (NOT stubbed) → verify new token in _client_kwargs, api_key, and the
  per-request client created by _create_request_openai_client.