[Feat]: Capture a claimant's reason for a name and expose it on the whitelist

Component

Registration

Priority

P1

Summary

When someone claims a name, they should say why they are entitled to it. A claim on a brand or a person's name, for example "google", can only be judged if the claimant explains who they are and why the name is theirs. Capture that reason when a claim is made, show it in the UI and the CLI, and expose it on the whitelist contract so operators and governance can read it before they accept or reject. Also let anyone check whether a name is already reserved before they claim it.

Part of the pre-launch reservation work (#203, #202); the claim surfaces are tracked in #206.

Proposal

• Reason on a claim. Add a reason field to the claim form in the UI and the CLI, and pass it through to the whitelist request path. The character limit is open for debate; keep any on-chain text short and hold longer justifications off-chain.
• Expose the reason. Make the reason readable from the contract, at a minimum in the request event so it can be indexed, and optionally through a view alongside the entry's status and timestamps. Full on-chain text is costly, so how it is stored is a design question: a short capped string inline, the reason in the event log only, or a hash pointer to off-chain text.
• Reserved lookup and search. Let a user search whether a name is reserved before claiming. A reserved name is one governance has marked as claimed and withheld from open claiming. A name that is not reserved can still receive a claim.
• Design question. For a name that is not reserved, may more than one person submit a claim to the same name, or is there a single pending claim that governance accepts or rejects? Record the decision.

Acceptance criteria

• The claim UI and CLI include a reason field with a defined and enforced character limit.
• The reason is passed to the whitelist request path and is readable on-chain, at least through the request event.
• Anyone can query whether a name is reserved.
• The character limit is decided and documented.
• The competing-claims question is answered and recorded: one pending claim per name, or several.

Start by tracing the claim form and CLI into the whitelist request path, then inspect the contract’s request event and reservation lookup. The work is done when the reason limit and competing-claims policy are recorded, the reason is readable on-chain, and users can query whether a name is reserved.