JNI initialization failures leak cached global references and are ignored

### Summary

`registerJniHelp` creates a global reference for `FileDescriptor` before resolving its constructor and fields.

Affected code:

- https://github.com/guardianproject/IOCipher/blob/859dff9b6d2b2794bd1b416dd08402fd487b6dc3/jni/JNIHelp.cpp#L289-L316
- https://github.com/guardianproject/IOCipher/blob/859dff9b6d2b2794bd1b416dd08402fd487b6dc3/jni/JNI_OnLoad.cpp#L41-L54

If any subsequent `GetMethodID` or `GetFieldID` call fails, the function returns without deleting `gCachedFields.fileDescriptorClass`.

Additionally, `JNI_OnLoad` ignores the return values of all registration functions and always reports successful initialization.

### Impact

A failed initialization can leave persistent global references and partially initialized cached fields. The library may then remain loaded in an inconsistent state, potentially causing later JNI failures or crashes.

### Suggested fix

- Resolve all method and field IDs using a local class reference first.
- Create the global reference only after every lookup succeeds, or use a shared failure-cleanup path that calls `DeleteGlobalRef`.
- Check every registration result in `JNI_OnLoad` and return `JNI_ERR` after cleaning up on failure.
- Add centralized cleanup for cached global class references.

Start by reading registerJniHelp in jni/JNIHelp.cpp at the referenced lines, then follow the registration flow in jni/JNI_OnLoad.cpp. Trace each lookup and registration return value alongside the cached global references. Done means failed lookups clean up references and JNI_OnLoad returns JNI_ERR after cleanup, while successful initialization remains unchanged.

Written by the indexing model from the issue text.