Raise cryptography ceiling to allow the patched 50.x

[matthewcummings]

Problem

The current constraint, cryptography = ">=48.0.1,<49.0.0", cannot resolve to a version free of known CVEs:

cryptography	Status
48.0.1	CVE-2026-69247, CVE-2026-69249
49.0.0	CVE-2026-69247
50.0.x	clean

Both CVEs were published 2026-08-03, before 2.11.3 was released, so every version the released constraint permits is affected. Downstream consumers have no workaround: anything satisfying the BDK is vulnerable, and anything patched fails resolution. It surfaces as a hard failure in image compliance scanning.

This is the second time in eight days the ceiling has blocked a security fix. #397 raised it from <47.0.0 to <49.0.0 for CVE-2026-34180, and it is already stale again.

Change

-cryptography = ">=48.0.1,<49.0.0"
+cryptography = ">=50.0.0,<51.0.0"

The bound is kept, just moved up to a range that contains a clean version. poetry.lock regenerated with Poetry 2.4.2, resolving cryptography 50.0.1. That is the only package change, none added or removed.

Verification

No new tests. This is a dependency constraint change, so the existing suite is the regression check. Run against the old pin and the new one to confirm the bump is not masking a regression:

cryptography	Result
48.0.1 (previous pin)	560 passed, 3 skipped
50.0.0	560 passed, 3 skipped
50.0.1 (newly locked)	560 passed, 3 skipped

Worth considering separately

Keeping a one-major ceiling means this recurs. cryptography has shipped a major roughly every five to seven weeks this year (47.0.0 in April, 48.0.0 in May, 49.0.0 in June, 50.0.0 in July), so <51.0.0 will likely go stale before October and block the next security fix the same way.

This project's cryptography surface is three imports of long stable APIs, all in symphony/bdk/core/auth/jwt_helper.py:

from cryptography.hazmat.primitives.serialization import Encoding, PublicFormat
from cryptography.x509 import load_pem_x509_certificate

idna is already declared without an upper bound here, so dropping the cryptography bound would not be a new pattern. Deliberately not doing that in this PR, since the priority is unblocking the CVEs, but it is worth a decision on its own.

Releasing

This PR also bumps version to 2.11.4, so merging it leaves main release-ready and the fix can go out without a second PR.

That is deliberate. #390 merged a constraint fix that then sat unreleased for five days until #397 bumped the version. The CVEs here are live in the released 2.11.3, so that gap matters this time.

Publishing still needs a maintainer to create and publish the GitHub release for v2.11.4, which triggers release.yml and poetry publish.