The Submit button was disabled on `meta.valid`, so an organiser with a
fully filled form could be left staring at a dead button with nothing on
screen explaining it. Reported from demo: title, dates, price, capacity,
payment methods and three named ticket waves all filled, no error text
anywhere, submit greyed.
Gating on `meta.valid` is a known vee-validate foot-gun:
- disabled fields count against form validity, and the maintainer
removed `disabled` from `<Field>` precisely because consistent
behaviour was unachievable. This dialog disables inputs while loading
and renders `fiat_currency` conditionally, so it is exposed.
- `meta.valid` is documented to go stale — false with zero errors after
a form is re-shown (logaretm/vee-validate#4630).
- it is false before the form has ever validated, which is why the docs
suggest `valid && dirty` rather than `valid` alone. A flag that is
unreliable in both directions should not be the only thing between an
organiser and their event.
So the button is now disabled only while a submit is genuinely in
flight, and the reasons come to the user instead:
- `handleSubmit`'s invalid callback names the offending fields in a
toast ("Check Tickets, Start date, Title"), opens whichever collapsible
holds one, and scrolls the first into view. Previously a FormMessage
inside a closed section was invisible.
- promo codes and ticket waves are not in the Zod schema, so
vee-validate cannot block on them; they are checked in the submit
handler, which opens their section rather than failing silently. Both
editors live inside collapsibles, so this was the same trap.
Verified in a browser: a blank form now has an enabled button, and
clicking it reports "Check Tickets, Start date, Title".
Refs aiolabs/events ticket-wave work; the report came from testing #176
on demo.
