Fix JNI stale local ref in OfflineStorage_Room record iteration loops

[hanselip]

Summary

Fixes #1227 — JNI abort (SIGABRT) occurring on Android when OfflineStorage_Room iterates over multiple records. The bug was introduced in commit 873b562 (Jan 2021) when per-record PushLocalFrame/PopLocalFrame calls were added.

Root cause: GetObjectClass() returns a local JNI reference. Local refs are freed by PopLocalFrame(). The code cached the returned jclass in an outer variable and reused it on iterations 1+, by which point PopLocalFrame() had already freed it. ART's JNI reference checker detects the stale ref passed to GetFieldID/GetMethodID and calls JniAbort() → abort() → SIGABRT.

Affected methods (all fixed):

• GetAndReserveRecords — record_class cached across iterations
• ReleaseRecords — bt_class cached across iterations
• GetRecords — record_class cached across iterations

Fix

Promote the jclass local ref to a JNI global ref via NewGlobalRef() on the first iteration. Global refs are not freed by PopLocalFrame() and remain valid until explicitly deleted with DeleteGlobalRef().

A GlobalRefGuard RAII struct (defined once in the anonymous namespace) handles cleanup on all exit paths — normal completion, break, std::logic_error (thrown by ThrowLogic), std::runtime_error (thrown by ThrowRuntime), and consumer() exceptions — which a post-loop DeleteGlobalRef would miss.

Additional hardening:

• NewGlobalRef null check (throws std::runtime_error on OOM, caught by existing handler)
• All jfieldID variables initialized to nullptr to prevent indeterminate values if ThrowLogic fires mid field-ID setup

Test

Added MultiRecordIterationFieldIdValidity regression test that:

• Stores 3 records and verifies all 3 are returned correctly by GetAndReserveRecords (exercises "reuse jclass on iteration 2+" path)
• Verifies GetRecords returns all 3 with correct field values
• Cycles GetAndReserveRecords + ReleaseRecords(incrementRetryCount=true) GetMaximumRetryCount()+1 times to exhaust retry counts, causing the Room impl to return a non-empty byTenant array — exercising the bt_class iteration path in ReleaseRecords with 3 loop iterations

All 83 non-Android unit tests pass (Room tests require Android device/emulator).

Note

Several other methods (DeleteRecords, StoreSetting, GetSetting, StoreRecords) call pushLocalFrame but rely on the ConnectedEnv destructor to drain frames rather than explicit popLocalFrame. This is safe (the destructor always drains the stack) but inconsistent — left as a candidate follow-up.

[lalitb]

nit - This looks like a dead step: the static link still hardcodes libsqlite3.a instead of using the sqlite3 CMake target/path that was just set up. But should be harmless to let it be :)

[lalitb]

LGTM. Thanks, the CI is breaking not related to the PR.