Bump litellm pin to skip PYSEC-2026-2 (1.82.7+1.82.8) but allow 1.83.0+

[freeoscloud]

Context

pyproject.toml line 17 + requirements.txt line 2 both pin litellm with the same expression:

litellm>=1.70.0,<1.82.7  # pinned to avoid PYSEC-2026-2 supply-chain compromise (1.82.7/1.82.8 were malicious)

The intent is correct — PYSEC-2026-2 documents that litellm 1.82.7 and 1.82.8 were malicious supply-chain releases. The current pin avoids those two versions.

The pin is now stale, however, because litellm 1.83.0+ is published, audited, and clean. The current <1.82.7 upper bound forces downstream consumers onto litellm 1.82.6, which has two unrelated security issues that were fixed in 1.83.0:

CVE	Severity	Description	Fix
CVE-2026-35030	CRITICAL	LiteLLM proxy — authentication bypass + privilege escalation	1.83.0
CVE-2026-35029	HIGH	LiteLLM proxy — RCE + privilege escalation	1.83.0

Both target LiteLLM's proxy mode specifically, but Trivy + other scanners flag them on any installed litellm package metadata regardless of whether the proxy is used. Downstream projects that include OpenSpace as a dep cannot pass image-level CVE gates without suppressing both.

Proposed change

Replace the pin with one that skips the malicious window AND allows current safe versions:

pyproject.toml:
```diff

• "litellm>=1.70.0,<1.82.7", # pinned to avoid PYSEC-2026-2 supply-chain compromise (1.82.7/1.82.8 were malicious)

• "litellm>=1.70.0,!=1.82.7,!=1.82.8", # skip PYSEC-2026-2 supply-chain compromise (1.82.7/1.82.8 were malicious)
  ```

requirements.txt: (same shape, no quotes)

The != exclusions are tighter than <1.82.7 — they block exactly the bad versions, not "everything ≥ 1.82.7" — and let consumers benefit from upstream litellm fixes.

Reproducer

• Clone OpenSpace, install via pip install -e . into a fresh venv that already has litellm>=1.83.0
• pip will downgrade litellm to 1.82.6
• trivy fs <venv-path> reports CVE-2026-35030 + CVE-2026-35029 against litellm-1.82.6.dist-info/METADATA

Happy to PR if useful

The change is a one-character substitution per file. I can open a PR if that's helpful — let me know.

(Filed by an OpenSpace consumer running into the issue downstream; tracking as PHOENIX-435-FU2 in our internal backlog.)