Update Creator Studio drop edits

Update an existing ERC-721 SeaDrop V1 drop and its stages. Only the collection owner can call it, and any other drop type returns 400.

Saves a Creator Studio draft. It does not change the live drop: SeaDrop stages are onchain contract state, so the draft has to be published separately before buyers see it. A 200 here means the draft was accepted, not that the drop changed.

stages replaces the whole set rather than merging, so send every stage the drop should end up with, including ones you are not changing. It is required even to change only max_supply or creator_payout_address. Reuse an existing stage uuid to update it, supply a new UUID to add one, and omit a stage to delete it. Every stage needs a label, and every price must be in the chain's native currency, with price.contract_address set to 0x0000000000000000000000000000000000000000.

A stage with a price above zero needs a creator payout address, the wallet that receives mint proceeds: SeaDrop reverts every paid mint while the contract has none. If the contract has no payout address yet, send creator_payout_address with the stages; a save with a paid stage and no payout address anywhere returns 400. Free stages need none.

Once minting has started, a save that raises max_supply or the price of the stage being minted from can be refused with 400. A drop whose supply or price is raised onchain during its mint is disabled.

The stage list has four rules, and rules 2 and 4 interact in a way worth reading before the first attempt:

1. Exactly one stage must be public_sale.
2. That public stage must be first in the array.
3. The presales, meaning every stage after the first, must be contiguous among themselves: each one starts exactly when the previous presale ended. The first presale start time is not constrained.
4. The last presale must end exactly when the public stage starts.

Together, 2 and 4 mean array order is not chronological order: the public stage is listed first and runs last, with the presales running in array order before it. A drop with two allowlist stages therefore sends [public, presale1, presale2] while time runs presale1, then presale2, then public. Rule 3 does not tie presale1 back to the public stage, which is why the chain reads forward from presale1 rather than from the array head.

Each stage's max_total_mintable_by_wallet is what that stage adds for a wallet, not a running total. Limits add up across the stages a wallet is listed on, the public stage adds its own limit on top, and mints a wallet leaves unused carry into later stages. So presales of 2 and 1 plus a public limit of 1 let a wallet on both lists mint 4.