v0.2.0:3 — durable payment-provider switching (Option B)

Closes the gap from :2 where Connect Zaprite swapped the
in-memory provider but BTCPay would silently re-take active on
the next daemon restart (because the boot-time loader picked
BTCPay first whenever btcpay_config was present, regardless of
operator intent).

What changed:

**New settings key `active_payment_provider`** in the existing
settings table. Records the operator's last explicit choice
('btcpay' | 'zaprite' | NULL = no preference). Both
btcpay_config and zaprite_config can coexist; the flag is what
determines which one the daemon loads.

**Boot-time loader respects the preference.** main.rs now reads
the flag at startup. If set to 'zaprite', Zaprite wins; if set to
'btcpay', BTCPay wins; if unset (legacy installs), falls back to
the previous BTCPay-first ordering. Cross-load fallbacks log a
WARN and try the other provider — operators with a stale flag
pointing at a wiped config don't boot unconfigured.

**Connect endpoints write the preference.**
- finish_connect (BTCPay) now sets the flag to 'btcpay' on
  successful authorize-callback completion.
- ZapriteAuthorize::connect now sets the flag to 'zaprite' on
  successful API-key validation.
- Both Disconnect endpoints clear the flag IF it pointed at the
  provider being disconnected — but leave it alone if it pointed
  at the OTHER provider (different operator intent).

**New endpoints for fast switching without re-Connect:**
- GET /v1/admin/payment-provider/status — both configs' state +
  current preference + runtime active provider, in one call.
- POST /v1/admin/payment-provider/activate { provider: "btcpay" |
  "zaprite" } — flips the active provider and the flag together,
  without going through the full Connect flow. 400 if the named
  provider isn't configured (operator must run Connect first).

**New StartOS Actions** under existing groups:
- "Activate BTCPay" (in BTCPay group)
- "Activate Zaprite" (in Zaprite group)
Both call the new activate endpoint. Operators with both
providers configured can flip back and forth in one click.

**Test:** payment_provider_preference_round_trip pre-seeds both
configs, walks through Activate-Zaprite → Activate-BTCPay →
attempt-Activate-on-wiped-config → bad-provider-name → manual
write/read of the preference key. Pins the contract.

Test count: 42 (was 41; +1).

Migration not needed — settings table from 0005 already has the
key/value/updated_at shape we need.

licensing-service/src/api/btcpay_authorize.rs

@@ -308,6 +308,19 @@ async fn finish_connect(state: &AppState, state_token: &str, api_key: &str) -> A
             .with_public_base(state.config.btcpay_public_url.clone()),
     );
     state.set_payment_provider(provider).await;
+    // Persist active-provider preference so the boot-time loader
+    // picks BTCPay on next restart even if Zaprite's config row
+    // is also still in the DB. Failure here is non-fatal (BTCPay
+    // is the historical default, so the fallback loader picks it
+    // anyway) but logged.
+    if let Err(e) = crate::payment::write_active_provider_preference(
+        &state.db,
+        crate::payment::ProviderKind::Btcpay,
+    )
+    .await
+    {
+        tracing::warn!(error = %e, "failed to record BTCPay as active payment provider");
+    }
 
     tracing::info!(
         store = %store.id,
@@ -392,6 +405,21 @@ pub async fn disconnect(
     // attempts return BtcpayNotConfigured cleanly.
     state.clear_payment_provider().await;
 
+    // If BTCPay was the recorded active-provider preference, clear
+    // it. Don't blindly clear if it was Zaprite — different operator
+    // intent.
+    if matches!(
+        crate::payment::read_active_provider_preference(&state.db).await,
+        Some(crate::payment::ProviderKind::Btcpay)
+    ) {
+        let _ = crate::db::repo::settings_set(
+            &state.db,
+            crate::payment::SETTING_ACTIVE_PROVIDER,
+            None,
+        )
+        .await;
+    }
+
     let _ = crate::db::repo::insert_audit(
         &state.db,
         "admin_api_key",