Deleting is its own permission

Deleting now needs a scope of its own. waitlists:write and signups:write used to carry removal along with creation, which meant the most common key in the product — a server handling a signup form — could erase any signup on the account despite never having a reason to.

What changed:

• Two new scopes: waitlists:delete for DELETE /v1/waitlists/:id, and signups:delete for DELETE /v1/waitlists/:id/signups/:signupId. The write scopes no longer grant either.
• Scopes are now fixed at the moment a key is minted. Checking every box grants everything that exists then, and nothing added later. Previously it stored *, which meant a key issued last month silently gained any permission invented since.
• Keys created before this change keep exactly the access they had — the wildcard was expanded into the five scopes that existed at the time, so none of them picked up the two new ones. Existing integrations are unaffected unless they delete, in which case mint a new key with the delete scope.
• Waitlists can now be renamed and deleted through the API, the SDK and the dashboard. Renaming changes an internal label only: ids, positions and referral codes all survive.

Deleting a waitlist takes every signup on it, permanently. Export first — the dashboard offers it inside the confirmation dialog, and the API has GET /v1/waitlists/:id/signups/export.