JVM SIGSEGV in native bcos_sdk_stop when stopping/destroying SDK or EventSubscribe

### Description
Calling the stop/destroy lifecycle on the SDK / `EventSubscribe` (which reaches native `bcos_sdk_stop` via `RpcJniObj.stop()`) crashes the JVM with `SIGSEGV` (process exit code 134).

### Environment
- macOS arm64 (Apple Silicon) running the x86_64 `fisco-bcos-macOS-x86_64` node and the SDK JNI via Rosetta 2
- bcos-sdk-jni 3.7.0, node v3.7.3, Java 8 (Zulu)

### Crash (hs_err)
```
# A fatal error has been detected by the Java Runtime Environment:
# SIGSEGV (0xb) ... SEGV_ACCERR
# Problematic frame:
# C [libbcos-sdk-jni-aarch64.dylib+0x263bb0] bcos_sdk_stop+0x140
Current thread: JavaThread "Test worker" [_thread_in_native]
j org.fisco.bcos.sdk.jni.rpc.RpcJniObj.stop()V+0
j
```
The crash is in native `bcos_sdk_stop`, triggered from the Java stop/destroy path — consistent with a use-after-free / double-stop on the native handle (related to the AMOP/eventsub lifecycle, where the JNI object may be stopped/freed more than once or while callbacks are in flight).

### Impact
Apps or tests that build an SDK / `EventSubscribe` and then `stop()`/`destroy()` it can hard-crash the JVM. (It also silently wipes JaCoCo coverage data, because a native crash bypasses the JVM shutdown hook.)

### Suggested investigation
Make the native stop path idempotent and null-/freed-checked (stop subscriptions before freeing the RPC object; guard against double `bcos_sdk_stop`). This may ultimately live in bcos-sdk-jni / bcos-c-sdk rather than this Java repo — feel free to transfer.

### Found via
A filter/eventsub integration test that called `stop()`/`destroy()`, during #947.