plans: names live orders as built

plans/names-codes/2026-10-21-store-api.md

@@ -48,7 +48,7 @@ The service serializes the requests that create or change an order:
 - every reservation, release and spending of a prepaid code runs one at a time per code, and reserving is one conditional update (`unused` and not reserved → reserved by this registration) in the transaction that creates, moves or requeues the registration;
 - every write to a registration is a compare-and-set on the `version` it read (section 6). A request that loses the race changes nothing and answers `409 {"error": "registration_changed", "registration": {…the current view}}`, on every endpoint that writes a registration (the reveal, `/name`, `/code`, `/retry`, cancel), so the page always follows the current state.
 
-The database backs this with unique constraints: one live registration per commitment, one live registration per owner and label hash, one registration per reserved code. A registration is live while it has an open invoice, or is past `unpaid` and not `taken` or `code_issued`; `live` is a stored flag, and every transition that changes it does so in the same transaction.
+The database backs this with unique constraints: one live registration per commitment, one live registration per owner and label hash, one registration per reserved code. A registration is live while it can still lead to a registration of its name: `unpaid` with an open invoice, `queued`, `committed`, revealing or registering, `failed` (retry is allowed), and a paid `taken` order until it is moved or turned into a code. A `registered` order is not live, so the same wallet can order the name again after it lapses; a code order that ends `taken` is not live. `live` is a stored flag, and every transition that changes it does so in the same transaction.
 
 **An overdue order is closed by the next order.** When a new order from the same wallet and name meets a live order whose open invoice has passed its expiry time (the poller may not have marked it yet), the new order closes it inside its own transaction, under the label hash's turn: the old invoice becomes `expired`, its registration loses `live`, and only then is the new order inserted. The provider's cancel of the old invoice is sent afterwards, best effort, as the poller would. Settlement queues a registration only while it is still live; a payment that arrives for a closed order is a late payment (it stays `unpaid`, the operator is alerted, and support refunds it), never a second live order.