A pick made on the map reaches the estimate, and one prefix means one observer

[khagele]

Two things that both let a Step 2 decision go somewhere other than where the operator thought it went.

Finishing on the map applies what you picked (#129)

Switching which node represents a prefix in "Resolve on map" only ticked a checkbox in the Step 2 list. That panel is off-screen from the map on most windows, so Done resolving ended the mode with the pick stranded in a list the operator could not see, and the map redrew from applied state — back on the old pick, reading as if the click had not registered.

Leaving the mode now applies. applyClusterEditor() is pulled out of the button handler and used by both Apply Inside Locked Cluster and Done resolving, which keeps the single apply path #33 asked for: weights carry over, nothing reimplements the read.

Only that button applies. switchToRegion() and syncControlStates() drop manual mode too, but they are abandoning the locked cluster, and applying on the way out would write picks into a region the operator just left.

Adding a prefix adds one observer (#130)

The Step 2 list holds every candidate a prefix resolved to, so matching on the prefix and ticking each row activated both nodes of an ambiguous prefix at once. A single prefix then contributed twice, from positions that can be tens of km apart, and pulled the estimate to somewhere between them — silently. It also ticked proven-link support nodes, which are range-only and never represent a prefix.

Add now picks one node per prefix: the one dedupeByPrefix() kept, a support node only as a last resort, and it says when there was more than one candidate rather than presenting the choice as settled (#85). Swapping stays in "Resolve on map", where the geometry is visible. A prefix the operator already has active is left alone.

Verified

Driven against the running page with a rebuilt locked cluster: prefix 2C on two nodes 40 km apart, plus a support node.

case	result
map pick, then Done resolving	active aaa, bbb → aaa, ccc, status "Locked cluster updated with 2 active observers"
Done resolving with nothing changed	nothing applied, weights untouched
weight typed, then Done resolving	aaa:0.4 applied
Apply Inside Locked Cluster	unchanged after the refactor (aaa:2.5)
pending pick, then Choose Another Cluster	not applied
add 2C, two candidates, none active	only bbb added, status names the 2 candidates
add 2C while the operator picked ccc	left alone
add a prefix only a support node carries	added, as last resort
add a prefix outside the cluster (7A)	"None of those prefixes are inside the locked cluster. Not found here: 7A."

Changelog entry for each, per AGENTS.md §7.

Closes #129
Closes #130

🤖 Generated with Claude Code