Rework the bind tool around the transmitter's identity

One string carried both transient status and the UID bytes, and it lived
in the page subtitle -- so the header changed meaning as you used it, and
the only value the tool read back had no home of its own. Split it into a
phrase form, an identity block, and feedback attached to the control that
caused it.

Drop "Request UID". Every event it existed to cover -- the target selector
moving, a first read falling silent -- is one the App can observe, so the
probe runs on tool open, after each write and on a target change, keeping
the bounded six-attempt retry that reports a pre-4.1 module.

Stop reading the receiver at all. It answers only over a link, and a link
only exists between devices already sharing a UID, so its answer could
never differ from the transmitter's -- while the link's presence says the
same thing for free and costs no over-air traffic. The row now reports
Connected / Not connected, and the simulator no longer seeds the two
devices with different UIDs, a state the radios cannot be in.

Bind and Unbind confirm before acting, which is where the advice belongs:
the firmware reaches EnterBindingModeSafely at either address, so "unbind"
puts the receiver into bind mode rather than erasing its binding, and the
other half of the pairing is still the user's to do. The Set button
carries the write sequence's progress instead of a floating status line,
which frees the row that restores [EXIT] on 128x64.

Set also moves to its own row with fixed text, the phrase field stays
editable regardless of what is reachable, and a Both write no longer flips
the selector to Transmitter behind the user.

Author: jurgelenas

README.md

@@ -85,10 +85,19 @@ The main tool (`SCRIPTS/TOOLS/ExpressLRS/`) lets you configure your ExpressLRS t
 ## ExpressLRS Bind Phrase Manager
 
 The bind tool (`SCRIPTS/TOOLS/ExpressLRSBind/`) sets the bind phrase -- or a raw UID entered as
-comma-separated bytes -- on the transmitter, the receiver, or both in one sequence, reads the
-current UID back for verification, and can put the TX in bind mode or unbind a connected receiver.
-The last five phrases are kept as a pick-and-send history. Setting the phrase over MSP requires
-**ExpressLRS 4.1+** on the device.
+comma-separated bytes -- on the transmitter, the receiver, or both in one sequence, and can put the
+TX in bind mode or unbind a connected receiver. The last five phrases are kept as a pick-and-send
+history.
+
+The transmitter's UID is read back automatically -- when the tool opens, after every write, and
+whenever you change the target -- so the page always shows the identity the handset is transmitting
+on. The receiver's own UID is not read: a receiver only answers over an active link, and a link only
+exists between devices that already share a UID, so its answer could never differ from the
+transmitter's. What is worth knowing is whether it is there at all, which the link reports for free.
+
+Setting the phrase over MSP requires **ExpressLRS 4.1+** on the device; a pre-4.1 module never
+answers, and the tool says so in the transmitter row rather than retrying forever. Bind and unbind
+are plain CRSF commands and work on every ExpressLRS version.
 
 <img src="screenshots/tool_bind_bw.png" width="256" alt="ExpressLRS Bind Phrase Manager"><br/>
 

docs/development.md

@@ -43,14 +43,21 @@ The configuration tool, `SCRIPTS/TOOLS/ExpressLRS/`:
 
 The bind phrase manager, `SCRIPTS/TOOLS/ExpressLRSBind/` (sets the bind phrase / UID over MSP;
 the device side requires ExpressLRS 4.1+, and a pre-4.1 device simply never answers -- the tool's
-bounded UID retry reports that instead of polling forever):
+bounded UID retry reports that instead of polling forever).
+
+Only the transmitter's UID is read, and only on the events that can change it: the tool opening, a
+write completing, and the target selector moving. The receiver is never asked. It answers over the
+link, a link only exists between devices already sharing a UID, so its answer is the transmitter's
+number by construction; the link's presence carries the whole of what asking would have told us, and
+costs no over-air traffic. That is also why there is no manual refresh -- every event a "read UID"
+button existed to cover is one the App observes for itself:
 
 | Module | Purpose |
 |--------|---------|
-| `main.lua` | Entry point and the App layer: target selection (TX/RX/Both), phrase-vs-raw-UID parsing, the two-step Both sequence (RX first -- writing its phrase drops it off the link -- then TX), the bounded UID read retry, and the frame router over `crsf.drain` |
+| `main.lua` | Entry point and the App layer: target selection (TX/RX/Both), phrase-vs-raw-UID parsing, the two-step Both sequence (RX first -- writing its phrase drops it off the link -- then TX), the bounded transmitter UID probe, and the frame router over `crsf.drain` |
 | `history_storage.lua` | The last five phrases, newest first, persisted through `file_storage.lua` as indexed keys `h1`..`h5` |
 | `ui/lvgl.lua` | Color LCD interface |
-| `ui/lcd.lua` | BW LCD interface (line list, phrase editing through `ui/lcd/text_edit.lua`) |
+| `ui/lcd.lua` | BW LCD interface (line list, phrase editing through `ui/lcd/text_edit.lua`). Note `popupConfirmation`'s message argument never reaches the screen on BW: EdgeTX's Lua binding sets `warningInfoText` without `warningInfoLength` (`api_general.cpp` `luaPopupConfirmation`), so a confirmation has only its 24-char title (`WARNING_LINE_LEN`) to say what it needs |
 
 Both tools pick their UI chunk at runtime -- `local useLvgl = (lvgl ~= nil)` -- and load exactly one
 of `ui/lvgl.lua` or `ui/lcd.lua`; there are no per-radio builds.
@@ -123,13 +130,14 @@ The simulator supports multiple test scenarios, configurable via the `config.sce
 ### MSP bind traffic
 
 The mock answers the bind tool's MSP `RXTX_CONFIG` traffic: a UID read (`MSP_REQ`) is served from a
-per-device `mspUid` table -- the TX and RX deliberately start with different UIDs so a fresh `normal`
-run shows a mismatch that setting both to one phrase visibly fixes -- and a phrase write
-(`MSP_WRITE`) rederives the target's UID through a deterministic pseudo-hash, so equal phrases give
-equal UIDs (the property the Both flow demonstrates; the bytes need not match the firmware's MD5).
-The RX answers only while the scenario keeps it reachable, which is what exercises the tool's
-bounded retry, and writes are unacknowledged just like the real firmware. `FRAMETYPE_COMMAND`
-bind/unbind requests are log-only.
+per-device `mspUid` table, and a phrase write (`MSP_WRITE`) rederives the target's UID through a
+deterministic pseudo-hash, so equal phrases give equal UIDs (the property the Both flow
+demonstrates; the bytes need not match the firmware's MD5). Both devices start on the same UID,
+because a reachable receiver whose UID differs from the transmitter's is a state the radios cannot
+be in. The RX answers only while the scenario keeps it reachable, and writes are unacknowledged just
+like the real firmware. `FRAMETYPE_COMMAND` bind requests are log-only -- note that the firmware
+handles that command identically at either address (`EnterBindingModeSafely`), so the "unbind"
+button puts the receiver into bind mode rather than erasing its binding.
 
 `config.maxPacketBytes` (default 64, `CRSF_MAX_PACKET_LEN`) is the largest frame the mock handset
 link carries. Parameter entries longer than `maxPacketBytes - 8` are chunked exactly as

screenshots/tool_bind.png

@@ -1258,12 +1258,13 @@ end
 -- MSP bind UID state
 -- ============================================================================
 
--- Per-device bind UID, read and written over MSP RXTX_CONFIG. TX and RX
--- deliberately start different so a fresh "normal" run shows a mismatch
--- that setting both to one phrase visibly fixes.
+-- Per-device bind UID, read and written over MSP RXTX_CONFIG. Both start
+-- on the same UID: a receiver only answers over a link, and a link only
+-- exists between devices that already share one, so a reachable RX whose
+-- UID differs from the TX's is a state the radios cannot be in.
 local mspUid = {
   [CRSF.ADDRESS_TX] = { 13, 213, 105, 32, 0, 1 },
-  [CRSF.ADDRESS_RX] = { 13, 213, 105, 32, 0, 2 },
+  [CRSF.ADDRESS_RX] = { 13, 213, 105, 32, 0, 1 },
 }
 
 --- Derive a deterministic 6-byte UID from bind-phrase bytes: the same