fix(deps): require litellm>=1.93.0 for Python 3.14 support

[nicoloboschi]

Problem

The local daemon fails to start on systems where Python 3.14 is the default interpreter (#2783). uvx resolves an old litellm, whose Rust extension refuses to build:

error: the configured Python interpreter version (3.14) is newer than
PyO3's maximum supported version (3.13)
  Current version: 0.23.5

Root cause

litellm ships its own Rust extension — litellm-rust/crates/python-bridge → litellm.rust_bridge._native, built with maturin/PyO3. (Not tokenizers, which is a red herring: tokenizers 0.23.1 has cp314 wheels and installs fine.)

	litellm 1.92.0	litellm 1.93.0
Wheels	cp310–cp313	cp310–cp314
py3.14	no wheel → sdist → PyO3 0.23.5 rejects >3.13, build fails	cp314 wheel (Linux) / sdist builds clean

Two things worth knowing:

• --dry-run cannot detect this. Resolution happily selects the sdist; only a real install surfaces the build failure.
• litellm publishes zero macOS wheels (manylinux only), so macOS builds from the sdist on every version. That is why the reporter (macOS) hit it: the 3.13 sdist built, the 3.14 sdist did not.

Fix

Raise the floor to litellm>=1.93.0 in hindsight-api-slim and hindsight-integrations/litellm, fixing the failure at its source rather than constraining the interpreter.

This lets us drop the UV_PYTHON=3.13 workaround from #2801 — _set_uvx_python_compat() and its call sites are removed from the claude-code, codex, cursor, and cursor-cli daemons, along with the tests pinning that behaviour. Removing the pin costs nothing: macOS needed a Rust toolchain either way, and Linux now gets a real cp314 wheel instead of a source build.

CI

build-api-python-versions already had 3.14 in its matrix, but ran only uv build — which packages the source and passes even when the dependency set cannot install or import on the target interpreter. It would not have caught this. It now installs into a fresh venv, byte-compiles, and runs an import smoke test on each version.

Verification

• CPython 3.14.4, UV_PYTHON unset → litellm 1.93.0 installs, Rust bridge builds, hindsight_api + engine import cleanly
• Reproduced the 1.92.0 failure and confirmed 1.93.0 resolves it
• Integration suites green: claude-code 201, codex 92, cursor 82, cursor-cli 89, zcode 99
• 77 api-slim litellm tests pass on the bumped version; lint.sh clean

Note

The floor only protects hindsight-api versions published after this bump. The old pin lived in the integration wrapper, so it also shielded already-published versions (the daemon runs uvx hindsight-api@{version}). A user pinned to an older hindsight-api on 3.14 will still resolve an old litellm until they move to a release carrying this floor — inherent to fixing it at the dependency level.

Refs #2783