[Feat]: Pre-launch name reservation: reserve names for claimants, not whitelisted minting

Component

Registration

Priority

P1

Summary

The whitelist was meant to reserve names for an intended owner. As built it does the opposite. An address added through whiteListAddress can call registerReserved on the registrar controller to mint any available name at zero cost, with no per-name binding and no cap. The constraint that forced this shortcut, rapid iteration, no longer holds. Replace it with a pre-launch flow where anyone can claim a username, operators approve the claim, and the approved name is reserved to the claimant so only they can register it. This is a tracking issue; the work is split into the sub-issues below.

Proposal

Release plan, end to end:

1. A claim window opens about one week before launch. Anyone submits a username claim through the UI or CLI.
2. Operators approve or reject each claim in the reservation contract. Approvals are operator calls, not referenda, so no new governance track is needed to run the window. Governance involvement is postponed (see #205)
3. An approved claim writes a reservation binding the name to the claimant's address in a dedicated reservation contract.
4. From launch, only the reserved claimant can register that exact name through the normal flow. The name is not minted for them; they register it themselves.
5. Operators are appointed and removable by the contract owner, which can also revoke any request or reservation directly. The owner is the root authority for this contract; who holds it on mainnet is decided in #211.
6. The reservation contract accepts new claims only inside the window and disables new requests once it closes. Open and close times are set by governance.

Retire the current path: registerReserved, whiteListAddress, isWhiteListed, onlyWhiteListedOrOwner, the WhiteListed event and NotWhiteListedOrOwner error stop being the mint gate. WHITELIST_OPERATOR_ROLE holders move to managing the reservation contract.

Sub-issues:

• #203 Name reservation contract with a bounded request window
• #204 Enforce reservations in registration and migrate off the address whitelist
• #206 UI and CLI claim surfaces

Open decisions, to settle across the sub-issues:

• One per person: bind to personhood (one verified person, one name), a fixed per-address cap, or no on-chain cap with the governance track vetting.
• Pricing: does the claimant pay the normal price for the name's length when they register it, or is it waived.
• Reservation lifetime: does an approved but unregistered reservation lapse on a timer (as with MAX_RESERVATION_TIME) or persist until released.

Acceptance criteria

• All sub-issues closed.
• No address can mint an unbounded number of arbitrary names at zero cost.
• A reserved name is registrable only by its designated claimant, and only that name.
• New claims are rejected outside the request window.
• The three open decisions are recorded with the chosen answer.

This is a tracking issue; start with sub-issues #203, #204, and #206 rather than implementing it directly. Read the reservation contract, registration flow, and UI/CLI work identified there, then confirm that all sub-issues are closed, the three open decisions are resolved, and the listed acceptance criteria hold.