search stays, no alerts for search edge cases. inline instead

plans/2026-09-22-name-lookup-core-api.md

@@ -45,7 +45,7 @@ None of it is reachable:
 
 **Scope.** Core only: types, producer, CLI rendering, generated client types, tests. No Kotlin, no Swift, no migration, no new chat command.
 
-**Not in scope, deliberately.** Registration, renewal and pricing actions — those are #7530, which consumes this API for its own name check rather than duplicating it (§7). No name-resolution cache or TTL in core: the once-a-day rule is expressible with the modes that already exist (§5).
+**Not in scope, deliberately.** Registration, renewal and pricing actions — those are #7530, which consumes this API for its own name search rather than duplicating it (§7). No name-resolution cache or TTL in core: the once-a-day rule is expressible with the modes that already exist (§5).
 
 ---
 
@@ -185,7 +185,7 @@ Registry and network failures stay `CPError` (2h). The canvas shows the resolver
 1. **The term is dropped from lookup wording, not added to the API.** Adding a term to `NamePricing` means a simplexmq change and a re-pin for one string; hardcoding "2 years" in three clients means three silent lies the day the term moves. Per-year pricing is what the registry actually returns. The registration canvas confirms the term is not the registry's to give: its 5e (desktop and F-Droid) shows "YOU PAY — A code, 2 years" with **no amount**, while 5 shows "$20, 2 years" on a store build. The amount is the store product's and the term comes with it, or with `NameCredit.years` on the code path. Registration 1d draws lookup 2c as "$20 for 2 years" and takes that rewording with it.
 2. **3c is a `Bool` on the `Ok` plans, not a revived `ownerChanged`.** It carries no owner and needs nothing persisted, so it does not reopen `f3bcd4a16`, and it is all the canvas claims.
 3. **Dateless alerts rather than suppressed ones.** A user on an old router still learns the name expired; only the two dates go.
-4. **Registration's check *is* this API, and dropping 5a/5b does not change that.** #7530 has nine name commands and not one of them asks the registry about a name, so the check behind Continue on registration §3 has no other source. It needs free / taken / reserved, and on a free name the pricing — exactly `CPNameNotConnectable` with `NRAvailable {pricing}`, `NRReserved`, or a `CAPOk` / `CAPKnown` plan when the name is taken. 5a and 5b are what that call already returns rendered: 5a is row 3a (`CAPKnown ct` + the contact's name), 5b is row 2a. So the `b898b991d` proposal ("suggest to drop 5a & 5b") is a decision about what to *show*, not about what to fetch — the coupling survives either way, and nothing here becomes removable, since every field 5a and 5b use is independently required by 3b and 3d.
+4. **Registration's search *is* this API.** #7530 has nine name commands and not one of them asks the registry about a name, so the search on registration §3 has no other source. It needs free / taken / reserved, and on a free name the pricing — exactly `CPNameNotConnectable` with `NRAvailable {pricing}`, `NRReserved`, or a `CAPOk` / `CAPKnown` plan when the name is taken. Registration 3b renders that answer inline instead of as the former 5a–5c alerts: a taken name shows its address, channel or both, and a tap opens the app's standard alert from the plan already in hand — lookup row 3a for `CAPKnown ct`, row 2a otherwise — so no second lookup is needed. Nothing here becomes removable, since every field 3b uses is independently required by lookup 3b and 3d.
 5. **The lookup canvas's footer line "registration will always resolve" is therefore accurate**, not obsolete, and stays on the sketch. It is the sentence that records the coupling in 4.
 6. **No cache in core.** §5 shows the rule is expressible with existing modes; a TTL column would be a migration bought for nothing.
 7. **One registry answer, one shape.** `ea721d33f` ("embed status. reduce") dropped the `NameResponse` import and replaced `NameStatus {response :: NameResponse, …}` with a bare `NameRegistration`, answering the review's "it would complicate things a lot". #7530 had re-added the import for `NameState {registration :: Maybe NameResponse}`, so the same registry answer reached the clients through two shapes for the sake of `lastBlockTs`, which nothing in chat-core reads. Reduced there to `Maybe NameRegistration`; `BSPName` keeps `NameResponse`, which is right — that is the service wire, not the app API.