feat(server,cli): auto-renew statement-store allowances

[pgherveou]

Why

Statement-store allowances are registered per UTC-day period (period = unix_seconds / 86400) and die at the boundary, ~12h average lifetime plus a ~1h grace, after which product statement submissions fail with "no allowance set for account". Per RFC-0010, keeping an allowance alive is the Account Holder's job; in the headless world the signing host plays that role, but it only registered allowances on demand for the current period and never renewed. This ports the mobile app's auto-renewal model into the shared core.

Design

Rule: core owns what to renew and how; the host owns only when.

 tick  (min(1h, next UTC-day boundary + 2min))
  ├─ no active session? ──────► skip
  ├─ read ledger, resolve targets against current root entropy
  ├─ fetch metadata + chain state + ring   (once per tick)
  └─ per target, under the registration lock:
       scan slots ── AlreadyAllocated ► fresh no-op
                 └── Free(seq) ► ring-VRF proof ► submit ► inBlock
                 └── exhausted ► stop pass, report slots_exhausted

• statement_allowance/renewal.rs — chain-pure pass reusing the existing register_statement_account orchestrator. No persisted (period, seq): chain state is the truth via the AlreadyAllocated fast path.
• signing_host/allowance_renewal.rs — target ledger persisted through CoreStorage (new StatementRenewalTargets slot). Entries are derivation recipes (WalletSso, ProductStatementAllowance{product_id}) so they survive the CLI's root-entropy rotation on slot exhaustion; only pairing peer device keys are raw account ids. Driver (renew_now) + idempotent loop spawned via Spawner (weak refs only, dies with the runtime; futures/futures-timer only, no tokio in core).
• A registration lock serializes the pass (held per target, so on-demand allocation waits at most one registration) with allocate_statement_store_allowance, which now also records its product target in the ledger.
• Public API on SigningHostRuntime (native-only): renew_statement_allowances() (primary one-pass entry, what a mobile WorkManager/BGTaskScheduler shim would call over FFI), start_statement_allowance_renewal(), track_statement_renewal_targets(), next_statement_renewal_delay().

CLI

• build_signing_runtime starts the renewal loop (covers startup and /session switches, all modes).
• Pairing registration returns the device key and tracks [WalletSso, device] in the ledger.
• New /renew command (interactive + signing-host exec '/renew') as the manual escape hatch: prints per-target outcomes and, on slot exhaustion, marks auto-managed accounts exhausted so the next pairing rotates.

Tests

• Tick-delay boundary math, outcome folding (mid-list failure continues; exhaustion skips the rest).
• Ledger round-trip / dedupe / order, strict decode, recipe resolution matches the sso_responder derivations.
• /renew parse accept/reject; codegen golden updated for the new CoreStorageKey variant.
• Gates: cargo +nightly fmt --check, clippy --workspace --all-targets --all-features -D warnings, cargo test --workspace, cargo check --target wasm32-unknown-unknown -p truapi-server (renewal is native-only; on web the paired mobile app is the Account Holder).

Follow-ups (out of scope)

• Bulletin long-term-storage renewal (additive ProductBulletinAllowance ledger variant).
• Core→host exhaustion callback so the background loop (not just /renew) can trigger account rotation.
• Move register_pairing_allowances into core to close the residual CLI-side registration race (benign: duplicate submits rescan).

[valentunn]

Note that mobile does that from a worker: doing so when app is running is not 100% reliable since the slot might expire when the app is not running
We should account that in the rust core: we want to be able to iniate & run stuff from the worker. One idea: rust core to send a command to native that it wants to schedule a specific / general purpose worker worker? We can (potentially, not sure) make "initiate worker" generic if rust core would pass opaque command data that worker will pass back to the core in onWorkerStarted or something like that