chore(deps): update xxhash requirement from <3.9,>=3.4 to >=3.4,<4.1

[dependabot]

⚠️ Dependabot is rebasing this PR ⚠️

Rebasing might not happen immediately, so don't worry if this takes some time.

Note: if you make any changes to this PR yourself, they will take precedence over the rebase.

---

Updates the requirements on xxhash to permit the latest version.

Release notes

Sourced from xxhash's releases.

v4.0.0

• Breaking change: Drop support for Python 3.8, require Python >= 3.9
• Breaking change: Remove deprecated xxhash.VERSION_TUPLE
• Breaking change: The input keyword argument is renamed to data across constructors, update(), and one-shot functions
• Breaking change: str input is no longer accepted and raises TypeError: Strings must be encoded before hashing; encode to bytes before hashing
• Upgrade xxHash from v0.8.2 to v0.8.3. Note: on GCC/Clang source builds that target AVX2 (e.g. -march=x86-64-v3), upstream v0.8.3 autovectorizes XXH64_update() and makes the xxh64 streaming path about 2x slower. The shipped wheels are built for baseline x86-64 and are unaffected. Source builds can work around it by adding -fno-tree-vectorize to the compiler flags.
• Add per-object locking for thread safety, with sub-interpreter and free-threaded (no-GIL) Python support
• Speed up hash constructors by switching them to tp_vectorcall.
• Build pyodide wasm32 wheels
• Add s390x big-endian test job
• Add Python 3.15 classifier
• CI: shard the PyPI upload into parallel groups and create the GitHub Release automatically

Changelog

Sourced from xxhash's changelog.

v4.0.0 2026-08-12

- **Breaking change**: Drop support for Python 3.8, require Python >= 3.9
- **Breaking change**: Remove deprecated ``xxhash.VERSION_TUPLE``
- **Breaking change**: The ``input`` keyword argument is renamed to ``data``
  in constructors and one-shot functions. ``update()`` additionally gains a
  ``data`` keyword argument (it accepted no keyword arguments before).
- **Breaking change**: ``str`` input is no longer accepted and raises
  ``TypeError: Strings must be encoded before hashing``; encode to
  ``bytes`` before hashing
- Upgrade xxHash from v0.8.2 to v0.8.3. Note: on GCC/Clang source builds
  that target AVX2 (e.g. ``-march=x86-64-v3``), upstream v0.8.3
  autovectorizes ``XXH64_update()`` and makes the xxh64 streaming path
  about 2x slower. The shipped wheels are built for baseline x86-64 and
  are unaffected. Source builds can work around it by adding
  ``-fno-tree-vectorize`` to the compiler flags.
- Add per-object locking for thread safety, with sub-interpreter and
  free-threaded (no-GIL) Python support. The GIL is now released only
  while hashing inputs larger than 64 KiB; previously ``update()``
  released it unconditionally and one-shot functions always held it.
- Speed up hash constructors by switching them to ``tp_vectorcall``.
- Build pyodide wasm32 wheels
- Add s390x big-endian test job
- Add Python 3.15 classifier
- CI: shard the PyPI upload into parallel groups and create the GitHub
  Release automatically
v3.8.1 2026-07-06

• Register the "benchmark" pytest mark to avoid PytestUnknownMarkWarning
• Update C extension docstrings and remove stale comments

v3.8.0 2026-06-27

- Speed up module-level one-shot ``digest()``, ``intdigest()``, and
  ``hexdigest()`` functions by switching them to ``METH_FASTCALL``.
- Keep one-shot argument handling consistent with hash constructors, including
  positional and keyword ``input``/``seed`` arguments, duplicate argument
  errors, and oversized seed wrapping.
- Fix error handling in the ``xxh3_128`` integer digest path so allocation
  failures are reported cleanly.
- Fix Python 3.8 builds by adding a ``PyModule_AddType`` compatibility
  fallback with correct reference counting.
- Correct type stubs for ``xxh64_digest()``, ``xxh64_hexdigest()``, and
  ``xxh64_intdigest()``, they were incorrectly aliased to xxh3_64 functions.
</tr></table>

... (truncated)

Commits

• 5c5e42f Release v4.0.0
• 88fe191 Bump version to 4.0.0.dev8
• 9628b66 Unify lock allocation and GIL release thresholds
• b274f52 Bump version to 4.0.0.dev7
• 39e4481 Simplify hash type name getters
• 8b83ba2 Bump version to 4.0.0.dev6
• af052b0 Unify invalid-keyword error message across constructors
• 51505c7 Bump version to 4.0.0.dev5
• 9b2bc9d fix: correct positional-seed tests in test_fastcall
• 94c3289 Update changelog for 4.0.0
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

This widens the range across a major-version boundary (< 3.9 → < 4.1), which pre-approves xxhash 4.x — a release that does not exist yet and whose API/behavior is by definition unconstrained by semver compatibility promises.

Two specific risks:

1. Digest stability. xxh3_128 hex digests are persisted in asset manifests and used for content-addressed storage keys (hash_file/hash_data in src/deadline/job_attachments/asset_manifests/hash_algorithms.py). If a future 4.x changes digest output, seeds/defaults, or hexdigest() byte order, previously uploaded CAS objects stop resolving and clients on different xxhash majors compute different keys for identical content — a silent cache-miss / re-upload problem rather than a loud failure.
2. API availability. from xxhash import xxh3_128 is an unguarded import; if 4.x renames or removes that symbol, this raises ImportError at hash time rather than at install time.

Neither can be validated today because there is nothing in 4.x to test against, so CI passing here only proves 3.x still works.

Suggest keeping the ceiling below the next major (e.g. xxhash >= 3.4,< 4.0) and raising it deliberately once 4.x ships and digest stability has been verified. If the intent was specifically to unblock a newly released 3.9/3.10, < 4.0 covers that too.