fix(agent): preload jiter native parser

[helix4u]

What does this PR do?

Preloads the OpenAI SDK's native jiter streaming parser during agent package import.

A Windows support report showed jiter.jiter could be imported directly from the Hermes venv, and Hermes launched from that same venv, but the first DeepSeek/OpenAI-compatible streaming request still failed with ModuleNotFoundError: No module named 'jiter.jiter'. Launching Hermes with jiter.jiter preloaded made the same session work, which points to an import-order/module-state problem in the threaded streaming path rather than a missing dependency.

The preload is best-effort. If jiter is truly missing or damaged, startup continues and the normal SDK request path still surfaces the underlying dependency error.

Related Issue

Support thread: API Call Failed - jiter.jiter

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• agent/jiter_preload.py: add an idempotent best-effort preload for jiter.jiter and jiter.from_json.
• agent/__init__.py: import the preload helper during agent package initialization so CLI, gateway, and other agent entry points get the same behavior.
• tests/agent/test_jiter_preload.py: cover successful preload and missing-extension fallback behavior.

How to Test

1. Reproduce on the affected Windows install: direct jiter.jiter import succeeds from the Hermes venv, but a normal DeepSeek streaming request fails with No module named 'jiter.jiter'.
2. Launch Hermes after this change and send the same DeepSeek test message.
3. Confirm the request no longer fails before delivery with No module named 'jiter.jiter'.

Local verification run:

./scripts/run_tests.sh -j 4 tests/agent/test_jiter_preload.py

Result: 2 passed.

Additional local sanity check:

./.venv/bin/python - <<'PY'
import agent
from agent import jiter_preload
print(jiter_preload._JITER_PRELOADED)
print(type(jiter_preload._JITER_PRELOAD_ERROR).__name__ if jiter_preload._JITER_PRELOAD_ERROR else 'None')
import jiter.jiter
print('jiter ok')
PY

Result: True, None, jiter ok.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: WSL/Linux local focused test; Windows behavior inferred from support repro and confirmed user workaround

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

Support report evidence:

• Direct venv import succeeded: jiter ok and jiter.cp311-win_amd64.pyd was present under the Hermes venv.
• Normal Hermes launch from .\venv\Scripts\hermes.exe still failed before delivery with No module named 'jiter.jiter'.
• Launching with import jiter.jiter, runpy; runpy.run_module('hermes_cli.main', run_name='__main__') worked.

[teknium1]

Merged via PR #33692. Your commit was cherry-picked onto current main with your authorship preserved in git log (commit 459d769).

Thanks for triaging the issue with Lucien on Discord and turning the workaround into a real fix — both the root-cause analysis (native .pyd load racing inside the SSE worker thread) and the best-effort preload approach landed verbatim.

Note on CI: 22/23 checks were green; build-arm64 failed twice with identical Azure blob cache SAS-token-expired-mid-download errors (~10-min token lifetime vs. ~22-min cross-arch build). Unrelated to this change, so we merged via admin override so Lucien can pick up the fix on hermes update.

#33692