Expose the pro auto-renewing config key to Kotlin

[mpretty-cyro]

Expose the pro auto-renewing and grace-period keys, and the proof response's advisory fields

LibSession-Util-Android @ feature/pro-auto-renewing-glue → base main (a00aa4a).

Two user-profile JNI pairs (A and G), the proof response's two advisory fields, and a submodule
pin bump.

🔴 Cannot merge until libsession-util libsession-util#121 merges

The libsession-util submodule is pinned to b066ba27, which is UNMERGED. It contains
#121 (8e5634b8, the A /
auto_renewing key — an open PR), the G / grace-period key, and the proof-response parse for
account_auto_renewing and account_grace_period_duration, both required on a successful proof. Merging this wrapper first
would pin it to a commit that isn't on dev.

A reviewer looking at a glue diff has no reason to have libsession-util#121 in mind, so it is stated here as well as
in the commit message.

Not the -pfs branch. JasonFork/pro-auto-renewing-config-pfs carries an identical commit
subject with a different sha and is not a descendant — it rebases the same change onto the PFS
track, dragging that line in with it. gh pr view 121 --json headRefOid confirms 8e5634b8.

Merge order: libsession-util#121 → this → a LibSession-Util-Android release → the Android client's
libsessionUtilAndroidVersion bump → the client PR (session-android
feature/pro-status-refresh-unification), which is what needs these accessors.

Why this exists

Both keys are added to core only, and this wrapper had no binding for either — "the core change
landed" is not the same as "the accessor is reachable from Kotlin".

• A / auto_renewing — the client persists it into synced config beside the access expiry, so a
  linked device has the account state without its own fetch.
• G / grace period — needed because the access expiry the backend sends is the payment-due
  date, and coverage runs a further grace period past it. The backend states the contract at the site
  that builds the response: "expiry_ts + grace_period_duration is exactly when we stop serving".
  So entitlement ends at expiry + grace, which is what the grace indicator, the coverage-end wake and
  the startup gate all have to key off. Without G in config the gate cannot compute it at all.

Both follow the existing ProAccessExpiry shape: extern "C" pair, interface member, external
override. No new pattern. G crosses the boundary as seconds (jlong) and is presented as a
java.time.Duration on the Kotlin side, matching how the client already handles the wire value.

Known limitation — inherent to A, surfaced here

A is presence-only. set_pro_auto_renewing(false) erases the key rather than storing zero,
so through this accessor a stored false and "never written" are indistinguishable —
getProAutoRenewing() returns false for both.

That is libsession-util#121's encoding, not something this binding introduces, but this is where a Kotlin caller
meets it, so it is documented on the accessor itself rather than only at the call sites. Callers that
need to tell the two apart cannot, through this API.

Not included: a mirror of user_profile_has_pro_auto_renewing(). That predicate was proposed and
then withdrawn upstream as vacuous — under this encoding A is present if and only if its value is
1, so it would have returned the same bit as the plain getter in every reachable state. Nothing here
ever depended on it.

Verification — and what it does not rest on

A JNI signature mismatch is invisible at compile time and traps at runtime, so a green build is
not evidence for a change of this kind, and a reviewer cannot see the binding is correct from the
diff. Checked against the built artefact instead — app-play-debug.apk, all four ABIs:

arm64-v8a    A:get=1 set=1   G:get=1 set=1
armeabi-v7a  A:get=1 set=1   G:get=1 set=1
x86          A:get=1 set=1   G:get=1 set=1
x86_64       A:get=1 set=1   G:get=1 set=1

All four symbols present in every ABI — getProAutoRenewing, setProAutoRenewing,
getProGracePeriodSeconds, setProGracePeriodSeconds. APK built from this branch with the consuming
client change and checked immediately after. :app:assemblePlayDebug green; the client's suite is 219
tests / 0 failures against it.

The leg not run: there is no unit test for the binding in this repo. No JVM test here can load
libsession_util.so, which is why the evidence is a symbol check on the real artefact rather than a
test. Stating it rather than letting "verified" cover a check that wasn't possible.

Reviewer notes

• Why these are two jboolean/jlong pairs rather than an int with a sentinel.
  On Android the natural binding — mirroring the accessor directly above it — would be
  static_cast<jboolean>(-1) = 255 = JNI_TRUE, so "never stored" would silently reach Kotlin as
  "auto-renewing". jboolean is uint8_t; the narrowing is legal and produces no diagnostic.
• No t/T bump on either write path: both are backend-derived state like E, I and R, not user
  profile edits, and libsession omits the bump for them deliberately.
• G needs no presence check, unlike A. The backend sends grace = 0 whenever the subscription is
  not auto-renewing, so "unset" and "zero" describe the same account and both give expiry + 0. There
  is no state a caller could act on differently, so adding a predicate by symmetry with A would be
  copying the shape without the reason.
• 🔴 The proof-response fields are only meaningful on a SUCCESSFUL proof, and nothing enforces that.
  Core's parser returns on the failure path before filling them, so every non-OK outcome yields grace 0
  and renewing false from struct defaults — no presence flag, non-nullable type, nothing to trip over.
  Since the client writes them into presence-only config keys where false erases, a read outside a
  success branch can wipe a flag get_pro_status had correctly learned. Both properties say so. The
  protection is placement, not the type.
• The proof-response fields are non-nullable and accountExpiry is not. That asymmetry inside one
  class is deliberate: the two new fields are required on a successful proof, so a nullable type would
  be a lie inviting ?: false — and false written to a presence-only key erases it. accountExpiry
  keeps its 0-sentinel because it genuinely is absent on some outcomes.