deps(security): sync uv.lock with bumped cryptography/python-multipart floors (#2635, #2651)

[r266-tech]

The merged security floor bumps left the committed root uv.lock out of sync, so
the canonical lock still resolves the known-vulnerable versions.

Problem

• deps(security): bump cryptography floor to >=48.0.1 (GHSA-537c-gmf6-5ccf, HIGH) #2635 raised cryptography to >=48.0.1 (GHSA-537c-gmf6-5ccf, HIGH)
• deps(security): bump python-multipart floor to >=0.0.31 (GHSA-5rvq-cxj2-64vf, HIGH) #2651 raised python-multipart to >=0.0.31 (GHSA-5rvq-cxj2-64vf, HIGH)

pyproject.toml on main carries both floors, but the committed uv.lock still
pinned cryptography 46.0.5 and python-multipart 0.0.27. As a result
uv lock --check fails on main, and uv sync / Docker uv sync --locked
keep installing the vulnerable versions — the floor bumps don't actually take
effect for locked installs, and dependency scanners still flag the lock.

Fix

Regenerated with uv lock --upgrade-package cryptography --upgrade-package python-multipart:

• cryptography 46.0.5 → 49.0.0 (satisfies >=48.0.1)
• python-multipart 0.0.27 → 0.0.32 (satisfies >=0.0.31)
• embedded root requires-dist specifiers raised to match pyproject.toml

uv lock --check now passes (regenerated with uv 0.11.22, matching CI's
astral-sh/setup-uv@v7).

Note on the greenlet lines

The regeneration also drops 6 stale greenlet 3.3.2 s390x wheel entries that
current uv no longer locks for this resolution (leftovers from a lock generated
by an older uv). greenlet's version is unchanged, its sdist remains, and s390x
coverage for the other ~50 packages is untouched — this is the same kind of
lock-hygiene cleanup as #2242, and is required for uv lock --check to pass on
current uv.

Same family as the previously-merged #2242 (“remove stale critical dependency
locks”); complements the already-merged #2635/#2651.

[github-actions]

PR Code Suggestions ✨

No code suggestions found for the PR.