`amount_tickets` IS the remaining count — the backend decrements it on
every sale and increments `sold`, so the two describe the same tickets.
MyEventsPage subtracted one from the other, removing each sale twice.
Because remaining + sold is the original capacity, `amount_tickets <=
sold` first becomes true at exactly the halfway point. So the purchase
button disabled itself once an event had sold half its seats, and
"Tickets Available" under-reported all the way there.
The backend half of this shipped as aiolabs/events#59 in v1.6.1-aio.17,
which makes the mismatch worse rather than better: the server now sells
correctly while the webapp refuses to let anyone buy. On aio-demo three
events are past the threshold — "Tech Meetup" has 9 tickets left, shows
-2, and the button is dead. The API confirms they are sellable.
Also makes ticket capacity a required field, at least 1. A capacity of 0
used to mean "unlimited", but nothing on the backend agreed: both
api_get_event and api_ticket_create read `amount_tickets < 1` as sold
out, so a 0 produced an event that advertised unlimited tickets on the
card and returned 410 to every purchase. aiolabs/events#62 stops
publishing that lie; this stops the form creating it.
The payload check moves from falsy to `!== undefined`, which is what
unblocks the backend making the field required — a falsy check dropped
0 from the request entirely, so a server-side `ge=1` would have 422'd
this dialog for precisely the case users were picking.
Editing an existing zero-capacity event now opens with the field empty
rather than prefilled with 0, so the organiser has to choose.
Closes#173
