Bump fastapi minimum version to fix PYSEC-2024-38 (starlette DoS) (#871)

* security(deps): bump fastapi floor to >=0.109.1 (PYSEC-2024-38)

The [explorer] extra declared fastapi>=0.100.0, which allows the
vulnerable 0.109.0 (PYSEC-2024-38, HTTP response splitting). Raise the
floor to 0.109.1, the patched release. One-line change, no functional
impact -- the 0.109.x API is stable and backward-compatible.

Fixes #869

* fix(deps): bump fastapi to >=0.109.2 and python-multipart to >=0.0.7 for PYSEC-2024-38

PYSEC-2024-38 (CVE-2024-24762 / GHSA-2jv5-9r88-3w3p) is a ReDoS in
python-multipart < 0.0.7: an attacker sends a crafted Content-Type header
that causes catastrophic backtracking in the multipart regex, stalling the
event loop and causing a DoS on any endpoint that parses form data.

The original PR bumped fastapi to >=0.109.1, but that version pins
starlette<0.36.0,>=0.35.0 and cannot install starlette 0.36.2+ (which
contains the fix via python-multipart>=0.0.7). FastAPI 0.109.2 is the
first version that pins starlette>=0.36.3 (verified against PyPI metadata).

Two changes are necessary:
1. fastapi>=0.109.1 -> fastapi>=0.109.2: ensures starlette>=0.36.3 is
   installed as a transitive dependency, which in turn pulls the fixed
   python-multipart>=0.0.7.
2. python-multipart>=0.0.6 -> python-multipart>=0.0.7: closes the direct
   dependency path. python-multipart is listed explicitly in the explorer
   extra, so without this floor a resolver could still install 0.0.6 and
   leave the vulnerability present even with the fastapi bump.

The fix targets only the 'explorer' optional dependency group, which is
the only code surface where FastAPI and form-data parsing are used.
No functional API changes between 0.109.1 and 0.109.2; 239 Explorer tests
pass without modification.

* ci(security): gate pip-audit on explorer-extra dependency PRs, add changelog entry for PYSEC-2024-38

The Security workflow's pip-audit job ran weekly against a bare Python
env with none of Semantica's optional extras installed, and always
continue-on-error'd -- it would never have flagged the vulnerable
fastapi/python-multipart floors this PR fixes, or the first attempt at
the fix that left python-multipart>=0.0.6 in place. security-scan.yml's
Safety check has the same blind spot (only installs [llm-litellm]).

pip-audit now also runs on pull_request when pyproject.toml changes,
installs semantica[all] so it can actually see extras like [explorer],
and fails the build on findings for that trigger. Scheduled/dispatch
runs stay non-blocking pending a full pass over the [all] tree.

Also documents the fix (#871, closes #869) in CHANGELOG.md, including
the correction made during review after the original fastapi-only bump
turned out not to close the vulnerability.

* fix(deps): raise setuptools floor to >=83.0.0 (CVE-2026-59890), harden audit env

The new pull_request pip-audit gate (previous commit) caught this on its
first run: pip install -e ".[all]" resolved setuptools==79.0.1, vulnerable
to CVE-2026-59890 / GHSA-h35f-9h28-mq5c / PYSEC-2026-3447 (Unicode
normalization lets a MANIFEST.in exclude/prune pattern be bypassed on
macOS APFS/HFS+, leaking excluded files into a built sdist). Fixed in
setuptools 83.0.0.

[build-system] requires had the same too-permissive floor this whole PR
is about (setuptools>=61.0). Raised to >=83.0.0. Also upgrade pip/
setuptools explicitly in the Security workflow before running pip-audit,
since [build-system] requires only governs isolated build environments,
not the ambient one actions/setup-python provisions and pip-audit scans.

---------

Co-authored-by: Sameer Kadam <sskadam6305@gmail.com>
Co-authored-by: KaifAhmad1 <kaifahmad087@gmail.com>

.github/workflows/security.yml

@@ -4,6 +4,11 @@ on:
   schedule:
     - cron: '0 0 * * 1'
   workflow_dispatch:
+  pull_request:
+    branches: [main]
+    paths:
+      - 'pyproject.toml'
+      - '.github/workflows/security.yml'
 
 permissions:
   contents: read
@@ -16,6 +21,23 @@ jobs:
       - uses: actions/setup-python@5fda3b95a4ea91299a34e894583c3862153e4b97 # v7
         with:
           python-version: '3.11'
+      # Upgrade first: actions/setup-python's baked-in setuptools has been
+      # behind known-vulnerable floors before (e.g. PYSEC-2026-3447 /
+      # CVE-2026-59890, fixed in 83.0.0) regardless of what this project's
+      # own [build-system] requires -- that only governs isolated build
+      # environments, not the ambient one pip-audit scans here.
+      - run: python -m pip install --upgrade pip setuptools
       - run: pip install pip-audit
+      # Install the [all] extra so pip-audit sees every optional dependency
+      # group (fastapi, python-multipart, etc.), not just pip-audit's own
+      # deps. PYSEC-2024-38 (#869) shipped in the first place because
+      # neither this job (bare env, no extras) nor security-scan.yml's
+      # Safety check (installs only [llm-litellm]) ever had fastapi or
+      # python-multipart installed to look at.
+      - run: pip install -e ".[all]"
+      # PR runs gate on findings, since they're scoped to actual
+      # pyproject.toml changes under review. The schedule/workflow_dispatch
+      # runs stay non-blocking until a full pass over pre-existing findings
+      # across the whole [all] tree has been done.
       - run: pip-audit
-        continue-on-error: true
+        continue-on-error: ${{ github.event_name != 'pull_request' }}