refactor: drop the SatsPay/watchonly on-chain surface

v1.6.8 sells tickets on-chain through SatsPay charges — a per-purchase
watchonly address, a hosted charge page, and a webhook back into the
extension. We are not adopting that: on-chain goes through the fork's
native LndRestWallet support once core can mint purpose-bound receiving
addresses (aiolabs/lnbits#53). This is the parity note on #41, applied
as its own commit so the merge it follows stays a faithful diff of what
upstream shipped.

Removed:
- services: the five SatsPay/watchonly HTTP clients (and with them the
  only uses of httpx and typing.Any in that module)
- views_api: _get_watchonly_status, GET /events/onchain/status, the
  SatsPay charge branch of api_ticket_create, POST
  /tickets/{id}/satspay-webhook, PUT /tickets/{hash}/onchain-confirm
- models: EventExtra.onchain_{enabled,wallet_id,zeroconf,fasttrack},
  TicketExtra.satspay_charge_id, TicketPaymentRequest.satspay_charge_url
- frontend: the organiser's "Onchain payments" panel and its watchonly
  wallet picker, the per-ticket confirm-onchain button, the SatsPay
  charge-page redirect, and the wallet-status fetch behind them

`onchain` is no longer an accepted payment_method — there is no rail to
fulfil it until #41 lands, so accepting it could only fail later.

Kept as vocabulary for #41, in upstream's field names so it needs no
migration: TicketExtra.onchain / onchain_address and
TicketPaymentRequest.onchain_amount_sat.

35 routes register with no duplicates; ruff, black, prettier clean; 97
tests pass; mypy error set still identical to HEAD's baseline.

static/js/display.js

@@ -83,19 +83,13 @@ window.PageEventsDisplay = {
     },
     paymentMethodOptions() {
       // Options come from `paymentMethods` — the same list the backend
-      // validates against in `effective_payment_methods` — rather than being
-      // re-derived from per-method booleans. v1.6.8 added a second copy of
-      // this computed that built the list from `allow_fiat`/`onchain_enabled`
-      // instead; because it was defined later in the object it silently won
-      // the merge, and it offers a "Bitcoin" option for any event with
-      // `extra.onchain_enabled` even though the backend rejects `onchain`
-      // unless it is in `extra.payment_methods` (views_api: "not in
-      // effective_payment_methods"). Labels below are upstream's; the source
-      // of the list is ours.
+      // validates against in `effective_payment_methods` — rather than
+      // being re-derived from per-method booleans, so a rail the server
+      // would reject can never be offered. The `|| method` fallback covers
+      // a method with no label yet (on-chain, once #41 lands).
       const labels = {
         lightning: 'Lightning',
-        fiat: this.fiatCheckoutLabel,
-        onchain: 'Bitcoin'
+        fiat: this.fiatCheckoutLabel
       }
       return this.paymentMethods.map(method => ({
         value: method,
@@ -243,11 +237,6 @@ window.PageEventsDisplay = {
                 : this.paymentMethods[0] || 'lightning'
           }
         )
-        if (data.satspay_charge_url) {
-          window.location.href = data.satspay_charge_url
-          return
-        }
-
         const isFiat = Boolean(data.is_fiat)
         this.paymentReq = isFiat
           ? data.fiat_payment_request || null