fix: honour per-wave fiat when the organiser set an explicit rail list

Reported from aio-demo: an event with fiat enabled, Card offered at
checkout, and the purchase refused with "Fiat payments are not enabled
for this ticket wave."

`effective_payment_methods` returned the organiser's explicit
`extra.payment_methods` list before ever consulting the wave:

    explicit = list(...)
    if explicit:
        return explicit          # <- the wave never got a look in

So the `wave` argument I added for #61 did nothing in the common case.
The webapp always sets `extra.payment_methods` from its payment-method
checkboxes, which means the explicit path is the normal one, not the
exception — three layers then disagreed:

- the NIP-52 tag advertised `tickets_payment_methods: lightning,fiat`
  while omitting `tickets_allow_fiat`, contradicting itself
- the checkout rendered a Card button
- `api_ticket_create`, the only wave-aware check, refused the purchase

Asking about a specific wave means asking what a buyer can actually use
for it, so a rail that wave cannot honour is now dropped. The
event-level question (no wave) still reports every rail the organiser
enabled — that is what `/republish-all` and the admin views want.

Fiat-only rails on a non-fiat wave now yield an empty list, which is
honest: nothing is purchasable from that wave.

5 tests, including both publisher shapes with an explicit list — the
case that actually bit, and which the #61 tests missed because their
fixtures left `payment_methods` empty. 133 pass.

Does not fix the data on events already created through the webapp:
their waves were saved with `allow_fiat` unset, so those waves genuinely
cannot take fiat until toggled. That is aiolabs/webapp's side.

models.py

@@ -224,6 +224,14 @@ def effective_payment_methods(
     """
     explicit = list(getattr(event.extra, "payment_methods", []) or [])
     if explicit:
+        # The organiser's rail list is event-level, but fiat is a per-wave
+        # opt-in. Asking about a specific wave means asking what a buyer can
+        # actually use for it, so drop a rail that wave cannot honour —
+        # otherwise the NIP-52 tag advertises fiat and the checkout offers a
+        # card button that `api_ticket_create` then refuses with "Fiat
+        # payments are not enabled for this ticket wave."
+        if wave is not None and not wave.allow_fiat:
+            return [method for method in explicit if method != "fiat"]
         return explicit
     methods = ["lightning"]
     if wave.allow_fiat if wave is not None else event.allow_fiat:

tests/test_publish_active_wave.py

@@ -158,3 +158,38 @@ def test_advertised_wave_key_tracks_the_published_wave():
     # Published while nothing is on sale — a real state, distinct from the
     # NULL that means "never published".
     assert advertised_wave_key(_event([CLOSED_EARLY_BIRD])) == ""
+
+
+def test_published_rails_drop_fiat_when_the_advertised_wave_cannot_take_it():
+    """The webapp always sets `extra.payment_methods`, so the explicit-list
+    path is the normal one — and it used to ignore the wave entirely.
+
+    That published `tickets_payment_methods: lightning,fiat` beside an
+    absent `tickets_allow_fiat`, and a card button the purchase endpoint
+    then refused ("Fiat payments are not enabled for this ticket wave").
+    """
+    event = _event(
+        [
+            _wave("a", 10.0, 0, -10, -1, allow_fiat=True),
+            _wave("b", 25.0, 9, 0, 20, allow_fiat=False),
+        ]
+    )
+    event.extra.payment_methods = ["lightning", "fiat"]
+    tags = _tags(event)
+
+    assert "tickets_allow_fiat" not in tags
+    assert tags["tickets_payment_methods"] == "lightning"
+
+
+def test_published_rails_keep_fiat_when_the_advertised_wave_takes_it():
+    event = _event(
+        [
+            _wave("a", 10.0, 0, -10, -1, allow_fiat=False),
+            _wave("b", 25.0, 9, 0, 20, allow_fiat=True),
+        ]
+    )
+    event.extra.payment_methods = ["lightning", "fiat"]
+    tags = _tags(event)
+
+    assert tags["tickets_allow_fiat"] == "true"
+    assert tags["tickets_payment_methods"] == "lightning,fiat"

tests/test_ticket_models.py

@@ -172,3 +172,48 @@ def test_public_event_response_carries_waves():
 
     assert [w["id"] for w in body["extra"]["ticket_waves"]] == ["regular"]
     assert "promo_codes" not in body["extra"]
+
+
+# --- rails vs per-wave fiat --------------------------------------------------
+
+
+def _fiat_wave(allow_fiat: bool):
+    from ..models import TicketWave
+
+    return TicketWave(
+        id="w",
+        title="w",
+        opening_date="2030-01-01",
+        closing_date="2030-02-01",
+        currency="EUR",
+        price_per_ticket=10,
+        amount_tickets=5,
+        allow_fiat=allow_fiat,
+    )
+
+
+def test_explicit_rails_drop_fiat_for_a_wave_that_cannot_take_it():
+    """The organiser's rail list is event-level; fiat is per-wave.
+
+    Without this the NIP-52 tag advertises fiat and the checkout renders a
+    card button that `api_ticket_create` refuses with "Fiat payments are
+    not enabled for this ticket wave" (reported on aio-demo).
+    """
+    event = _event()
+    event.extra.payment_methods = ["lightning", "fiat"]
+
+    assert effective_payment_methods(event, _fiat_wave(True)) == ["lightning", "fiat"]
+    assert effective_payment_methods(event, _fiat_wave(False)) == ["lightning"]
+
+
+def test_event_level_question_still_reports_every_rail():
+    """No wave means "what did the organiser enable at all" — unfiltered."""
+    event = _event()
+    event.extra.payment_methods = ["lightning", "fiat"]
+    assert effective_payment_methods(event) == ["lightning", "fiat"]
+
+
+def test_fiat_only_rails_on_a_non_fiat_wave_leave_nothing_purchasable():
+    event = _event()
+    event.extra.payment_methods = ["fiat"]
+    assert effective_payment_methods(event, _fiat_wave(False)) == []