Fix JniCallback null check to test the NewGlobalRef result

[Sanjays2402]

Fixes #14974.

JniCallback's constructor creates a global ref for the Java callback object, but the guard checks jcallback_obj rather than m_jcallback_obj. Callers always pass a non-null local ref, so the branch is dead and a failed NewGlobalRef (OOM, with an exception pending) slips through. The object ends up with m_jcallback_obj == nullptr while the derived constructor keeps running and the native factory still hands back a handle.

While fixing that I hit a second problem on the same path. m_jvm and m_jcallback_obj are never initialized, so the early return when GetJavaVM fails leaves both indeterminate. ~JniCallback then reads m_jcallback_obj and can call DeleteGlobalRef on garbage, and getJniEnv uses a junk m_jvm before that. So:

• initialize both members in the ctor init list
• check m_jcallback_obj instead of the input
• bail out of the destructor when m_jvm is null, since there's nothing to release

The destructor guard is what makes the OOM case actually safe to unwind rather than just detected.

This base class backs the comparator, logger, event listener, table filter, WAL filter, trace writer, transaction notifier and write batch handler bridges, so it's a shared path.

Compiled java/rocksjni/jnicallback.cc clean against JDK 20 on macOS arm64. The behaviour only changes under allocation failure, which I don't have a good way to exercise in the existing Java test suite, so I've left it as a straight correctness fix with no new test.

As the issue notes, a base ctor can't stop the derived ctor body from running. Propagating construction failure out of the individual callback ctors and factory functions is the larger follow-up and isn't in this change.