[Bug] dbt-athena mmh3<4.2.0 constraint blocks Python 3.13

### Is this a new bug?

- [x] I believe this is a new bug
- [x] I have searched the existing issues, and I could not find an existing issue for this bug

### Which packages are affected?

- [ ] dbt-adapters
- [ ] dbt-tests-adapter
- [x] dbt-athena
- [ ] dbt-athena-community
- [ ] dbt-bigquery
- [ ] dbt-postgres
- [ ] dbt-redshift
- [ ] dbt-snowflake
- [ ] dbt-spark

### Current Behavior

`dbt-athena`'s [pyproject.toml](https://github.com/dbt-labs/dbt-adapters/blob/main/dbt-athena/pyproject.toml) pins `mmh3>=4.0.1,<4.2.0`. This upper bound blocks Python 3.13 installs entirely:

- `mmh3==4.1.0` (the highest in-range version) publishes no py3.13 wheels — only up to cp312 on PyPI.
- Building from source on py3.13 fails: mmh3 4.1.0's C source is incompatible with the Python 3.13 C API (`failed-wheel-build-for-install`).
- The 3.13 wheels ship with `mmh3` starting at 5.0.

Meanwhile the package classifiers advertise `Programming Language :: Python :: 3.13` and `requires-python = ">=3.10.0"`, so users on 3.13 hit an install failure with a misleading claim of support.

### Expected Behavior

Installation succeeds on Python 3.13 with a wheel-shipping version of `mmh3`.

### Steps To Reproduce

```
python3.13 -m pip install dbt-athena
# → ERROR: Failed building wheel for mmh3
```

Or, in a `python:3.13-slim` container:

```
pip install "dbt-athena-community==1.10.2"
# → dbt-athena==1.10.2 pulled in; mmh3==4.1.0 resolved; source build fails
```

### Relevant log output

```shell

```

### Environment

```markdown
- OS: any (repro confirmed on Debian 12 slim container)
- Python: 3.13.x
- dbt-athena: 1.9.5 through 1.11.0b2 all affected (same constraint)
```

### Additional Context

### Proposed fix

Relax the upper bound to allow `mmh3` 5.x (which does publish py3.13 wheels and preserves the `mmh3.hash()` API dbt-athena actually uses — see [`dbt-athena/src/dbt/adapters/athena/impl.py`](https://github.com/dbt-labs/dbt-adapters/blob/main/dbt-athena/src/dbt/adapters/athena/impl.py)):

```diff
- "mmh3>=4.0.1,<4.2.0",
+ "mmh3>=4.0.1,<6.0.0",
```

I've verified locally that `mmh3.hash(...)` on integers, strings, and bytes returns identical values on `mmh3==4.1.0` (py3.12) and `mmh3==5.2.1` (py3.13), so the `murmur3_hash` adapter method is unaffected by the bump.

Happy to open a PR against `main` if this diff is acceptable.