v0.2.0:45 — Zaprite recurring auto-charge + mobile-friendly admin UI

Two routine bumps land together in this release:

:44 — Admin UI mobile pass. Adds a phone breakpoint (≤640px) and
hamburger-driven off-canvas drawer (≤720px) to the embedded
web/index.html so triage flows (status check, license lookup, revoke)
work from a phone. Tables now scroll horizontally inside their card,
tap targets bump to ~40px, stats grid collapses to 1-up, toolbar
inputs go full-width. Desktop layout unchanged. CSS + small JS toggle.

:45 — Zaprite recurring auto-charge wired end-to-end. Closes the gap
the subscriptions.rs module comment promised but never delivered:
first-cycle invoices on recurring policies set allow_save_payment_profile,
the on-settle hook captures the resulting Zaprite paymentProfileId
into four new nullable columns on the subscriptions table (migration
0019, additive only), and the renewal worker calls
POST /v1/orders/charge against the saved profile instead of waiting
for manual pay. On charge failure (declined card, expired profile,
network) the worker logs + audits + falls through to the existing
subscription.renewal_pending event so the buyer still has a recovery
path. Two new operator webhook events: subscription.auto_charge_initiated
and subscription.auto_charge_failed. BTCPay subs and Zaprite subs
whose buyer paid with Bitcoin/Lightning or declined the save-card
prompt are untouched. NOT yet end-to-end tested against the Zaprite
sandbox — control flow follows api.zaprite.com/llms.txt but exact
failure-body shapes for declined cards aren't documented; sandbox
validation pass recommended before relying in production.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

licensing-service/src/payment/mod.rs

@@ -137,6 +137,15 @@ pub struct CreateInvoiceParams<'a> {
     pub external_order_id: &'a str,
     /// Buyer email if known. Some providers use this for receipts.
     pub buyer_email: Option<&'a str>,
+    /// Ask the provider to prompt the buyer to save their payment
+    /// profile for future merchant-initiated charges. Zaprite honors
+    /// this for autopay-supporting rails (Stripe card, etc.); BTCPay
+    /// has no equivalent concept and silently ignores it. Set
+    /// `Some(true)` on the FIRST cycle of a recurring purchase so the
+    /// renewal worker can later call `charge_order_with_profile`
+    /// against the saved profile. `None` / `Some(false)` is the
+    /// one-shot default.
+    pub allow_save_payment_profile: Option<bool>,
 }
 
 /// Result of `create_invoice`. Whatever the provider returned, narrowed