fix(backend): bump pip-audit --strict floors for 5 new advisories (CI #587)

[Sbussiso]

Summary

Fixes the Dependency scan (pip-audit) failure in Test & Deploy run #587 (run 32779502864).

pip-audit --strict reported 5 known vulnerabilities in 3 packages after new advisories landed in the PyPA Advisory DB:

Package	Version	Advisory	Fix
click	8.3.1	PYSEC-2026-2132	8.3.3
cryptography	48.0.1	PYSEC-2026-3552	50.0.0
cryptography	48.0.1	PYSEC-2026-3553	49.0.0
cryptography	48.0.1	PYSEC-2026-3554	49.0.0
pip	26.1.2	PYSEC-2026-3721	26.2

Root cause

The Backend tests job's Dependency scan (pip-audit) step runs uv run pip-audit --strict, which audits the entire resolved dependency tree against the PyPA Advisory DB. Three new advisories (one for click, three for cryptography, one for pip) landed after the last green run, turning the scan red even though no code changed. All three are transitive / dev-surface-only — none are direct dependencies, and pip itself isn't shipped in the app image (it's only present because pip-audit pulls it in to resolve deps).

Fix

Bump the [tool.uv] constraint-dependencies floors in backend/pyproject.toml, following the established pattern in this block (each entry cites the advisory and notes when the constraint can be removed):

• pip>=26.1.2 → pip>=26.2
• cryptography>=48.0.1 → cryptography>=50.0.0 (50.0.0 satisfies all three cryptography advisories)
• add click>=8.3.3 (new entry; transitive via uvicorn)

uv lock regenerates cleanly. The cryptography floor cascades clerk-backend-api 6.0.1 → 7.0.0 (accepted by its own version range).

Verification

Run locally in the sandbox (Python 3.12):

• ✅ uv lock — resolves 121 packages cleanly
• ✅ uv run pip-audit --strict — No known vulnerabilities found
• ✅ uv run ruff check — All checks passed
• ✅ uv run pytest -q — 699 passed in 12.75s

Notes

• This is independent of the dependabot bump (PR build(deps-dev): bump @testing-library/user-event from 14.6.3 to 14.6.5 in /frontend #204) that triggered run #587 — the advisories affect master directly and would block the next deploy, so this targets master.
• The constraints block documents when each floor can be removed (once the relevant direct dep's own pin clears the version).