LeveldbJournalNativeSpec fails on macOS ARM64 because leveldbjni-all lacks an arm64 library

### Description

`LeveldbJournalNativeSpec` fails on Apple Silicon because Pekko currently uses `org.fusesource.leveldbjni:leveldbjni-all:1.8`, whose macOS native library does not contain an ARM64 slice.

### Reproduction

Environment:

- macOS 26.5.1
- `uname -m`: `arm64`
- Java 25.0.1

Run:

```shell
sbt "persistence-tck / Test / testOnly org.apache.pekko.persistence.journal.leveldb.LeveldbJournalNativeSpec"
```

The same failure is reached from `validatePullRequest`.

Actual error:

```text
java.lang.UnsatisfiedLinkError: Could not load library
...
fat file, but missing compatible architecture
(have x86_64,i386, need arm64e or arm64)
```

### Root cause

`project/Dependencies.scala` defines:

```scala
val levelDBNative =
"org.fusesource.leveldbjni" % "leveldbjni-all" % "1.8" % "optional;provided"
```

The bundled macOS library reports:

```text
META-INF/native/osx/libleveldbjni.jnilib:
Mach-O universal binary with 2 architectures: x86_64 i386
```

It has no `arm64` slice.

### Workarounds investigated

The HawtJNI property `-Dlibrary.leveldbjni.path=` is recognized and attempts to load a library from the supplied directory. However, the ARM library in `org.openlabtesting.leveldbjni:leveldbjni-linux64-aarch64:1.8` is a Linux binary:

```text
ELF 64-bit LSB shared object, ARM aarch64
```

Pointing `library.leveldbjni.path` at that library on macOS fails with:

```text
slice is not valid mach-o file
```

The `org.openlabtesting.leveldbjni` group has four artifacts in Maven Central (`leveldbjni-project`, `leveldbjni`, `leveldbjni-linux64-aarch64`, and `leveldbjni-all`) and no macOS ARM64 artifact. Its `leveldbjni-all:1.8` still bundles the old `x86_64+i386` macOS library.

Huawei variants `1.8-hw-20191105` and `1.8-hw-aarch64` also add Linux AArch64 ELF libraries while retaining the old `x86_64+i386` macOS library.

### Possible direction

These Maven Central artifacts contain a real Mach-O ARM64 library and passed a local JNI open/put/get/close/destroy smoke test:

- `io.github.tronprotocol:leveldbjni-all:1.18.3`
- `com.halibobor:leveldbjni-all:1.23.2`

A replacement needs compatibility review before adoption: these artifacts use a different `org.iq80.leveldb` API dependency and do not bundle the Windows native DLLs present in the current artifact. A platform-specific test dependency or another approach may be needed to avoid regressions and non-reproducible published POMs.

### Expected behavior

The native LevelDB spec should either run successfully on macOS ARM64 with an Apache-compatible supported dependency, or the unsupported platform should be handled explicitly without breaking the full PR validation.

### References

- https://repo1.maven.org/maven2/org/fusesource/leveldbjni/leveldbjni-all/1.8/
- https://search.maven.org/solrsearch/select?q=g:%22org.openlabtesting.leveldbjni%22&rows=200&wt=json
- https://repo1.maven.org/maven2/io/github/tronprotocol/leveldbjni-all/1.18.3/
- https://repo1.maven.org/maven2/com/halibobor/leveldbjni-all/1.23.2/

Start in project/Dependencies.scala and run the persistence-tck command for org.apache.pekko.persistence.journal.leveldb.LeveldbJournalNativeSpec on macOS ARM64. Review the candidate leveldbjni-all artifacts and their org.iq80.leveldb and Windows-native compatibility before choosing an approach. Done means the native spec and validatePullRequest work on supported platforms without breaking published dependency metadata.

Written by the indexing model from the issue text.