Design: a verb's address is data, so the toolbar widget can stop existing

snaporca-7ih's remaining half. Both flyout factories registered their verbs INSIDE the
widget-building loop, so the ~40 retired tool buttons had to be constructed and then
Hide()n: skipping construction would have deleted 42 offer verbs (26 fly:<family>#<row>
+ 16 Shift+keys) while their rows still rendered and did nothing when picked.

Register first, build second. The addresses are pure data; the widget is one door onto
them, not their owner. A family absent from kBarKeep now returns before any wxWindow is
made. The keep-list stays a one-line data decision, not a structural one.

And close the class of bug for good: the constructor now verifies, once, that every verb
the atlas marks wired resolves to a real registration, logging each break and asserting in
debug. Rows that render and do nothing have shipped three times (edit_feature and sk_move
with action:null, then this) and are invisible from either side alone.

Verified on the snaporca rig by walking the offer, not by reading the code — all four
at-risk address kinds run with no widget behind them: fly:design_rect#2 drew an OBLIQUE
rectangle (the third variant, not the family's first), key:S+E opened Extrude with its
10 mm gizmo, fly:material#4 opened Thicken. Hover hints, icons and nesting intact. This
fork is code-identical here bar the two permitted DropDown divergences; it still owes a
build of its own (snaporca-5pl).

Two hints were wrong and are fixed: Cut said "Split the body with a plane", colliding with
the Split verb one row away and pointing at a card for a value the canvas already offers as
a draggable arrow; Split never said its plane comes from a picked face.

Also, because it blocked the verification and will block the next one: gui-session.sh
killed by full path while its own app_pid() matched by basename, so a differently-pathed
instance survived, held the single-instance lock, and got reported as a healthy session —
a Jul-30 binary nearly passed as this build. It now kills by basename and prints which
binary is actually on screen. Traps 6 and 7 documented.

scripts/gui-session.sh

@@ -53,6 +53,10 @@ status() {
     else echo "vnc     : DOWN"; fi
     local p; p="$(app_pid || true)"
     echo "app     : ${p:-DOWN}"
+    # WHICH binary is on screen, not just that something is. A pid alone cannot tell you whether
+    # you are looking at the build you just linked or one from last week, and that is precisely
+    # the question every rig verification is asking.
+    [ -n "${p:-}" ] && echo "binary  : $(readlink -f "/proc/$p/exe" 2>/dev/null || echo unknown)"
     [ -n "${p:-}" ] && echo "windows : $(xdotool search --name . getwindowname %@ 2>/dev/null | paste -sd'|' -)"
     return 0
 }
@@ -73,7 +77,15 @@ if ! pgrep -x x11vnc >/dev/null && command -v x11vnc >/dev/null; then
 fi
 
 # --- app ------------------------------------------------------------------------------------
-pkill -9 -f "$BIN" 2>/dev/null || true
+# Kill by BASENAME, not by "$BIN". The app enforces a single instance, so an older copy launched
+# from a DIFFERENT path (the packaged build/package/bin/ one, say, when BIN points at the freshly
+# linked build/src/Release/ one) survives a path-matched pkill, keeps the instance lock, and the
+# new process exits seconds after loading fonts — leaving no error anywhere. app_pid() below has
+# always matched by basename, so status then reported that stale process as a healthy session:
+# the launch looked green while the window on screen was days old. Measured 2026-08-02, where it
+# nearly passed a UI change against a Jul-30 binary. The killer and the reporter must agree on
+# what counts as "the app".
+pkill -9 -f "$(basename "$BIN")" 2>/dev/null || true
 sleep 2
 nohup "$BIN" >"$LOG" 2>&1 &
 echo "launched $(basename "$BIN") pid $!"