feat(registration): add gate mode (all|any) for alternative registration methods

The invite + payment gates were strictly conjunctive: a new wallet had to satisfy
EVERY enabled gate. Add a REGISTRATION_GATE_MODE knob so an operator can offer the
enabled gates as ALTERNATIVES instead (e.g. "an invite code OR pay to register").
PoW stays orthogonal and always applies on top, regardless of mode.

- config: GateMode { All (default) | Any } on RegistrationConfig, from
  REGISTRATION_GATE_MODE (default "all", back-compatible).
- capabilities: advertise registration_mode ("all"|"any") so the wallet can route
  onboarding (multiple gates + "any" => "pick a method"; "all" => satisfy each).
- enforcement: enforce_method_gates composes invite+payment per mode. Extracted a
  pure plan_gates() decision so the fund-critical dispatch is unit-tested. In
  "any" with both gates on, the client presents exactly ONE credential and only
  that gate runs (and only it consumes its single-use token); presenting BOTH is
  rejected so a one-of choice can never burn two tokens (an invite AND a paid
  invoice). Single-gate configs behave identically in both modes.

6 KATs on plan_gates (open / conjunction / single-gate / dispatch / reject-both /
require-one). openapi.json regenerated. 211 lib tests pass.

.env.example

@@ -66,6 +66,14 @@ PAYMENT_CURRENCY=XMR
 PAYMENT_CONFIRMATIONS=1
 PAYMENT_EXPIRES_MINUTES=60
 
+# How the enabled invite/payment gates COMBINE (PoW is orthogonal and always
+# applies on top). 'all' (default): a new wallet must satisfy EVERY enabled gate
+# (invite AND payment when both are on). 'any': the enabled gates are
+# ALTERNATIVES and the wallet satisfies exactly ONE (e.g. "an invite code OR pay
+# to register"); the client shows a "pick a method" chooser. With a single gate
+# enabled the two modes are identical.
+REGISTRATION_GATE_MODE=all
+
 # ── Bitcoin (Electrum/Fulcrum only; the backend runs no Core RPC node) ─────
 BTC_NETWORK=mainnet
 BTC_ELECTRUM_URL=