fix(deps): pin click >=8.3.3,<8.4 for PYSEC-2026-2132 (CI #534)

[Sbussiso]

Root cause

CI run #534 (30854789797) on dependabot/uv/backend/websockets-17.0.1 failed two independent audit gates:

Gate	Finding	Severity
Backend → pip-audit --strict	click 8.3.1 → PYSEC-2026-2132 (command injection in click.edit())	high
Frontend → npm audit --audit-level=high --omit=dev	react-router-dom 7.18.2 → GHSA-qwww-vcr4-c8h2 (RSC-mode CSRF bypass)	high

Neither is related to the websockets 16.1.1→17.0.1 bump this Dependabot branch carries — both are pre-existing vulns surfaced by the audit gates.

What this PR fixes — backend / click ✅

click is a transitive dependency pulled in via uvicorn (which only requires click>=7.0). Without an explicit floor, the resolver landed the vulnerable 8.3.1.

• Fix: add "click>=8.3.3,<8.4" to backend/pyproject.toml [dependencies] (minimum patched release on the 8.3 patch line; <8.4 keeps it patch-only — no minor bump), plus a matching constraint-dependencies entry.
• Regenerate uv.lock → click 8.3.3.

Local verification (all green)

uv run pip-audit --strict   → No known vulnerabilities found
uv run pytest -q            → 699 passed
uv run ruff check           → All checks passed

What this PR does NOT fix — frontend / react-router ⚠️ needs human decision

The frontend npm audit gate fails on GHSA-qwww-vcr4-c8h2 (RSC-mode CSRF bypass), react-router range >=7.12.0 <8.3.0. There is no safe version of react-router-dom available right now:

react-router-dom version	Status
7.0.0–7.11.0	vulnerable to 4 other high advisories (open-redirect→XSS GHSA-jjmj-jmhj-qwj2, SSR hydration constructor injection GHSA-337j-9hxr-rhxg, DoS via route matching GHSA-chx6-hx7r-mcp5, RSCErrorHandler XSS GHSA-h8fp-f39c-q6mh)
7.12.0–7.18.2 (current)	vulnerable to GHSA-qwww-vcr4-c8h2 (the failing advisory)
8.3.0+ (the documented fix)	react-router-dom has no 8.x release — latest is 7.18.2; only the framework package react-router has 8.x

A downgrade to 7.11.0 (npm's suggested "fix") trades one high vuln for four others — not safe. Pinning to 7.11.0 was tested locally and npm audit still reports high severity.

Why it may be acceptable to defer the frontend fix

The advisory is specifically about RSC (React Server Components) mode CSRF bypass. This codebase uses the classic declarative <BrowserRouter> + <Routes>/<Route> API (verified: only BrowserRouter, Routes, Route, Navigate, Link, useNavigate, useLocation, useParams, Outlet are imported — no RouterProvider, createBrowserRouter, Form, useFetcher, useActionData, or useLoaderData). The vulnerable RSC action-execution path is not reachable with this routing setup.

Recommended options (pick one)

1. --ignore-vuln the advisory temporarily in the frontend audit step (the workflow comment at .github/workflows/deploy.yml:297-308 already documents this escape hatch: "When a CVE shows up with no fix yet, add --ignore-vuln <ID> here with a comment citing the upstream issue and the date we plan to revisit.") — citing that the codebase does not use RSC mode.
2. Wait for react-router-dom 8.x (the react-router framework package already has 8.3.0, but the DOM bindings package has not been published for 8.x yet).
3. Migrate to the react-router framework package directly (larger change, out of scope for a CI-fix PR).

This PR is a draft so the backend fix can merge and unblock the websockets bump; the frontend advisory needs a decision on (1)/(2)/(3) above.

Scope

• backend/pyproject.toml — add click>=8.3.3,<8.4 to [dependencies] + constraint-dependencies
• backend/uv.lock — regenerated (click 8.3.1 → 8.3.3)
• Frontend: unchanged (no safe fix exists)

Hermes coder CI triage for run #534.