Pro glue: expose auto_renewing (key A) and grace period (key G)

[mpretty-cyro]

Pro glue: expose auto_renewing and the grace period, in config and on the proof response

Adds the libsession_util_nodejs bindings Session Desktop's Pro status-refresh work needs. No behaviour
change to anything existing — four new methods and two new response fields, nothing altered.

Three commits. The first exposes the synced user-profile config keys:

JS	core	shape
getProAutoRenewing() / setProAutoRenewing(bool)	user_profile_{get,set}_pro_auto_renewing	boolean
getProGracePeriod() / setProGracePeriod(graceMs)	user_profile_{get,set}_pro_grace_period	number (ms)

G holds the account-level grace_period_duration from get_pro_status — the response carries a
per-payment field of the same name, and only the account-level one is gated on auto-renewal. E is the
account's true paid-through expiry and the backend serves until E + G, so [E, E + G) is
expired-but-still-served. Both facts are stated at the declaration, since a caller with the wrong one
produces a plausible number that is weeks off.

Mirrors the existing getProPrepaid/setProPrepaid pair — implementation plus InstanceMethod
registration in src/user_config.cpp, declarations in include/user_config.hpp, and the three
declaration sites in types/user/userconfig.d.ts (interface, UserConfigWrapperNode, MakeActionCall
union).

The second surfaces two new fields on the generate_pro_proof response, so a proof fetch can refresh
those config keys alongside the access expiry rather than leaving them to desync:

JS	core	shape
accountAutoRenewing	GenerateProProofResponse::account_auto_renewing	boolean
accountGracePeriodMs	GenerateProProofResponse::account_grace_period	number (ms)

🔴 Both are non-null, and the hazard a nullable shape would have flagged is real — it just isn't
nullability. Core requires them
on a successful parse — a response missing either is a parse error, not a defaulted value — so a nullable
shape would describe a state that cannot occur. But on a failure outcome core never fills them and its
struct defaults (false / 0) come through, indistinguishable from a backend that really said "not
renewing, no grace". Both config keys are stored presence-only, so writing either would erase what a
get_pro_status fetch had learned.

So the protection is scope, not nullability: these two are meaningful only where status === 'ok', and
both declarations say so. A reviewer should treat any read of them outside a success branch as a defect.
accountExpiryMs stays nullable — it is still std::optional in core, absent on not_subscribed and
revoked.

⚠️ Depends on libsession-util#124 — not on #121 alone

A wrapper reviewer won't have this in mind, so stating it plainly. #121 is not sufficient: it introduces
config key A and has no pro_grace_period symbols at all, so setProGracePeriod/getProGracePeriod here
would not resolve. #124 completes #121 and carries all four commits this binds:

core commit	what this wrapper binds to it
8e5634b8 (#121's contribution)	user_profile_{get,set}_pro_auto_renewing
269f8b88	user_profile_{get,set}_pro_grace_period
f197a0bd	parse_pro_proof requiring account_auto_renewing + account_grace_period_duration
b066ba27 (#124's tip)	nothing directly — clearing E also erases A

They are a chain, so #124's tip is the single thing to depend on. b066ba27 binds no new symbol and is
listed because the presence-only caveat below refers to it: it is a correctness dependency for consumers
rather than a compile dependency here.

This PR cannot build until #124 is merged and the submodule pin moves.

What is verified, and what is not

Stated explicitly because "it compiled" is not available here:

• Verified by inspection: the four JS-side strings match their InstanceMethod registrations exactly.
  That pairing is unchecked at compile time on this platform — napi dispatch is by string — so it's worth
  saying it was checked rather than assumed. The core signatures were read from
  include/session/config/user_profile.hpp at 269f8b88, not taken from a description.
• Structural argument: the worker's dispatch is (wrapper as any)[action] with no registry or
  allow-list, so there's no third site to keep in sync; the two string literals are the whole surface. A
  missing or misnamed binding throws a named error on first call rather than failing silently.
• NOT verified: this was never compiled or executed. The submodule is deliberately left at its
  recorded commit, because neither core change is merged. So there is no artefact to inspect for symbols,
  and CI is the first real build. Two of three verification legs, by construction rather than by omission.

Two deliberate choices a reviewer may want to challenge

G is milliseconds on the JS side, converted to core's whole seconds here. The wrapper has two
conventions in tension: timestamps are ms-in-JS with C++ converting (setProAccessExpiry,
setProPrepaid, setRefundRequested), while the one existing duration accessor,
setNoteToSelfExpiry, takes seconds straight through. G is a duration in the Pro family. Chose ms
because callers hold gracePeriodDurationMs from the get_pro_status response, and it keeps the
conversion in one place instead of at every call site. The conversion floors, so a derived coverage end
(E + G) never claims coverage the backend didn't grant. Easy to flip if seconds is preferred.

G is not optional, unlike A. The backend sends 0 whenever the subscription isn't auto-renewing,
and E + 0 == E, so "no grace stored" and "a grace of zero" describe the same account. There's nothing
for a presence check to disambiguate, and adding one by symmetry with A would copy a trap rather than a
pattern.

Caveats documented at the declarations, not at call sites

The next reader of this glue won't have the design thread, so both live in the type declaration:

• A is presence-only. Core writes it with set_nonzero_int, so setProAutoRenewing(false) erases
  the key — present iff its value is 1. A caller must therefore not key a change check on whether the key
  is present. For "absent means not auto-renewing" to be sound, every writer of E must also write A —
  a client that writes E from a path carrying no renewing flag leaves the pair inconsistent. The clear
  side is handled in core as of b066ba27, so only the write side is the client's responsibility.
• E, G and A are only jointly meaningful when written from the same response. They're then
  internally consistent whatever grace was in force. No signature can enforce that, so it's stated.
  Clearing is handled below core — as of 269f8b88 clearing E erases G, and as of b066ba27 it
  erases A too — so a client need only take care to write them together.