This PR upgrade pyopenssl dependency. Current constraints is
`<24.3.0`(up to 24.2.x). New constratints is `<24.4.0`(up to 24.3.x).
This PR is for addressing security alert `GHSA-79v4-65xg-pq4g`.

GHSA-79v4-65xg-pq4g

// I guess this constratints is for pyopenssl->cryptography migration.
IdentityPython#977
IdentityPython@735bfa5

Applies [@praushcer](https://github.com/prauscher)'s changes to remove pyopenssl.

see [upstream IdentityPython#977](IdentityPython#977)

Replace pyopenssl with cryptography (upstream PR IdentityPython#977)

Unblock the wedged dependency security updates: dependabot's pyjwt security
job fails on every run (security_update_not_possible) because
grafana-django-saml2-auth — archived by Grafana 2026-06-16, frozen at
3.21.0 forever — pins pyjwt==2.12.1 via django-saml2-auth-community, whose
pysaml2==7.5.4 pin in turn caps pyopenssl<24.3.0 and transitively
cryptography<44. The Pipfile.lock had drifted unsound (cryptography 48.0.1
alongside pyopenssl 24.2.1's <44 cap), so any honest pipenv relock
downgraded cryptography five majors onto two HIGH advisories.

Approach: convert the root app from pipenv to uv (the toolchain /mcp_server
already uses) and declare the one-line resolver override
`pyopenssl>=26.2`, lifting pysaml2's stale cap so pyopenssl/cryptography
float together honestly. Swap the dead grafana distribution name for
django-saml2-auth-community>=3.22.0 (identical django_saml2_auth import
paths; no code changes). Resulting lock: pyjwt 2.13.0, cryptography 49.0.0,
pyopenssl 26.3.0 — fully consistent, no unsoundness. Django stays 5.2.15.

Pros:
- Every blocked security update lands via honest resolution; the recurring
  red dependabot job and its deploy-gate fallout end
- One dependency toolchain repo-wide; dependabot's uv updater runs
  `uv lock`, so the override survives every future bot PR
- Production precedent for this exact override: Flagsmith's SAML stack

Cons:
- Overriding pysaml2's metadata asserts pyopenssl>=26.2 compatibility;
  verified empirically (standard SP flows execute no pyOpenSSL code), but
  validate_certificate/PEFIM cert-generation must stay off until pysaml2
  ships IdentityPython/pysaml2#977 or #1021 (override removable then)
- Contributors switch pipenv muscle memory to `uv run`/`uv sync`

Full analysis, alternatives considered, and retirement triggers:
docs/rfcs/0002-dependency-security-unblock-uv-migration.md

Unblock the wedged dependency security updates: dependabot's pyjwt security
job fails on every run (security_update_not_possible) because
grafana-django-saml2-auth — archived by Grafana 2026-06-16, frozen at
3.21.0 forever — pins pyjwt==2.12.1 via django-saml2-auth-community, whose
pysaml2==7.5.4 pin in turn caps pyopenssl<24.3.0 and transitively
cryptography<44. The Pipfile.lock had drifted unsound (cryptography 48.0.1
alongside pyopenssl 24.2.1's <44 cap), so any honest pipenv relock
downgraded cryptography five majors onto two HIGH advisories.

Approach: convert the root app from pipenv to uv (the toolchain /mcp_server
already uses) and declare the one-line resolver override
`pyopenssl>=26.2`, lifting pysaml2's stale cap so pyopenssl/cryptography
float together honestly. Swap the dead grafana distribution name for
django-saml2-auth-community>=3.22.0 (identical django_saml2_auth import
paths; no code changes). Resulting lock: pyjwt 2.13.0, cryptography 49.0.0,
pyopenssl 26.3.0 — fully consistent, no unsoundness. Django stays 5.2.15.

Pros:
- Every blocked security update lands via honest resolution; the recurring
  red dependabot job and its deploy-gate fallout end
- One dependency toolchain repo-wide; dependabot's uv updater runs
  `uv lock`, so the override survives every future bot PR
- Production precedent for this exact override: Flagsmith's SAML stack

Cons:
- Overriding pysaml2's metadata asserts pyopenssl>=26.2 compatibility;
  verified empirically (standard SP flows execute no pyOpenSSL code), but
  validate_certificate/PEFIM cert-generation must stay off until pysaml2
  ships IdentityPython/pysaml2#977 or #1021 (override removable then)
- Contributors switch pipenv muscle memory to `uv run`/`uv sync`

Full analysis, alternatives considered, and retirement triggers:
docs/rfcs/0002-dependency-security-unblock-uv-migration.md

… uv migration (RFC 0002) (#679)

* chore(deps): migrate root app to uv; swap to django-saml2-auth-community

Unblock the wedged dependency security updates: dependabot's pyjwt security
job fails on every run (security_update_not_possible) because
grafana-django-saml2-auth — archived by Grafana 2026-06-16, frozen at
3.21.0 forever — pins pyjwt==2.12.1 via django-saml2-auth-community, whose
pysaml2==7.5.4 pin in turn caps pyopenssl<24.3.0 and transitively
cryptography<44. The Pipfile.lock had drifted unsound (cryptography 48.0.1
alongside pyopenssl 24.2.1's <44 cap), so any honest pipenv relock
downgraded cryptography five majors onto two HIGH advisories.

Approach: convert the root app from pipenv to uv (the toolchain /mcp_server
already uses) and declare the one-line resolver override
`pyopenssl>=26.2`, lifting pysaml2's stale cap so pyopenssl/cryptography
float together honestly. Swap the dead grafana distribution name for
django-saml2-auth-community>=3.22.0 (identical django_saml2_auth import
paths; no code changes). Resulting lock: pyjwt 2.13.0, cryptography 49.0.0,
pyopenssl 26.3.0 — fully consistent, no unsoundness. Django stays 5.2.15.

Pros:
- Every blocked security update lands via honest resolution; the recurring
  red dependabot job and its deploy-gate fallout end
- One dependency toolchain repo-wide; dependabot's uv updater runs
  `uv lock`, so the override survives every future bot PR
- Production precedent for this exact override: Flagsmith's SAML stack

Cons:
- Overriding pysaml2's metadata asserts pyopenssl>=26.2 compatibility;
  verified empirically (standard SP flows execute no pyOpenSSL code), but
  validate_certificate/PEFIM cert-generation must stay off until pysaml2
  ships IdentityPython/pysaml2#977 or #1021 (override removable then)
- Contributors switch pipenv muscle memory to `uv run`/`uv sync`

Full analysis, alternatives considered, and retirement triggers:
docs/rfcs/0002-dependency-security-unblock-uv-migration.md

* docs(rfc): fill in companion PR number (#679)

* docs(rfc): add live-deployment validation of the SAML gap (§5)

* docs(rfc): confirm SAML gap from inside the deployed machine (§5)

* chore(deps): refresh lock post-rebase — track main's django 5.2.16, pick up cryptography 50

Rebasing over the merged 2026-08-01 dependabot batch (#682–#692) required
re-resolving: bump the exact django pin to match main's #689 and run
uv lock --upgrade so the uv lock carries everything the batch delivered
under pipenv — django-oauth-toolkit 3.4.0, faker 40.36.0, boto3 1.43.64 —
plus cryptography 50.0.0/pyopenssl 26.4.0, superseding both artifacts
main's #692 relock introduced (cryptography 43.0.3 downgrade and the
duplicate grafana/community saml distributions in Pipfile.lock).

Full backend suite passes locally on the refreshed lock (977 passed).

* docs(rfc): record Simon's allauth end-state for SAML; update version tables (§2, §5, §6)

Simon's review answer (2026-08-04): allauth now backs patient login and
password reset, so SAML should ideally live there too. §5 gains a
Resolution recording the community-fork swap as transitional with
django-allauth[saml] as the destination, notes the xmlsec1/libxmlsec1
Docker gap carries over to python3-saml rather than disappearing, and §6
trigger 3 becomes the planned retirement path. §2's table refreshed to the
post-rebase lock (cryptography 50.0.0, pyopenssl 26.4.0) and documents the
now-live main artifacts this PR supersedes.

* docs(rfc): tighten RFC 0002 — half the length, same content

Reviewer feedback: the RFC read as verbose and partly redundant. Condensed
each section (279 → ~160 lines), folded the visible-breakage list into the
problem narrative, absorbed the post-#692 main drift into §1, refreshed the
version table to the current lock (cryptography 50.0.0, django 5.2.16), and
replaced §5's superseded follow-up-issue/xmlsec-carries-over wording with the
final resolution (#697 / RFC 0003). No substantive positions changed.